idnits 2.17.1 draft-ietf-roll-security-threats-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IS07498-2' is mentioned on line 157, but not defined == Unused Reference: 'RFC4107' is defined on line 1748, but no explicit reference was found in the text == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on line 1776, but no explicit reference was found in the text == Unused Reference: 'IEEE1149.1' is defined on line 1793, but no explicit reference was found in the text == Unused Reference: 'RFC3830' is defined on line 1843, but no explicit reference was found in the text == Unused Reference: 'RFC4046' is defined on line 1847, but no explicit reference was found in the text == Unused Reference: 'RFC5055' is defined on line 1860, but no explicit reference was found in the text == Unused Reference: 'RFC5197' is defined on line 1864, but no explicit reference was found in the text == Unused Reference: 'RFC5996' is defined on line 1888, but no explicit reference was found in the text == Unused Reference: 'Szcze2008' is defined on line 1895, but no explicit reference was found in the text == Unused Reference: 'Wander2005' is defined on line 1908, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-04 == Outdated reference: A later version (-06) exists of draft-kelsey-intarea-mesh-link-establishment-05 -- Obsolete informational reference (is this intentional?): RFC 1142 (Obsoleted by RFC 7142) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Over Low-Power and Lossy Networks T. Tsao 3 Internet-Draft R. Alexander 4 Intended status: Informational Cooper Power Systems 5 Expires: April 23, 2014 M. Dohler 6 CTTC 7 V. Daza 8 A. Lozano 9 Universitat Pompeu Fabra 10 M. Richardson 11 Sandelman Software Works 12 October 20, 2013 14 A Security Threat Analysis for Routing over Low-Power and Lossy Networks 15 draft-ietf-roll-security-threats-05 17 Abstract 19 This document presents a security threat analysis for routing over 20 low-power and lossy networks (LLN). The development builds upon 21 previous work on routing security and adapts the assessments to the 22 issues and constraints specific to low-power and lossy networks. A 23 systematic approach is used in defining and evaluating the security 24 threats. Applicable countermeasures are application specific and are 25 addressed in relevant applicability statements. These assessments 26 provide the basis of the security recommendations for incorporation 27 into low-power, lossy network routing protocols. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in RFC 34 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 23, 2014. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 4 73 3.1. Routing Assets and Points of Access . . . . . . . . . . . 5 74 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 7 75 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 8 76 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . 11 77 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 79 5.1. Threats due to failures to Authenticate . . . . . . . . . 13 80 5.1.1. Node Impersonation . . . . . . . . . . . . . . . . . 13 81 5.1.2. Dummy Node . . . . . . . . . . . . . . . . . . . . . 13 82 5.1.3. Node Resource Spam . . . . . . . . . . . . . . . . . 13 83 5.2. Threats and Attacks on Confidentiality . . . . . . . . . 13 84 5.2.1. Routing Exchange Exposure . . . . . . . . . . . . . . 14 85 5.2.2. Routing Information (Routes and Network Topology) 86 Exposure . . . . . . . . . . . . . . . . . . . . . . 14 87 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . 15 88 6.1. Routing Information Manipulation . . . . . . . . . . . . 15 89 6.2. Node Identity Misappropriation . . . . . . . . . . . . . 15 90 7. Threats and Attacks on Availability . . . . . . . . . . . . . 16 91 7.1. Routing Exchange Interference or Disruption . . . . . . . 16 92 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 16 93 7.3. Communications Resource Disruption . . . . . . . . . . . 18 94 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . 18 95 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 19 96 8.1. Confidentiality Attack Countermeasures . . . . . . . . . 19 97 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . 19 98 8.1.2. Countering Passive Wiretapping Attacks . . . . . . . 20 99 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 21 100 8.1.4. Countering Remote Device Access Attacks . . . . . . . 21 101 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . 22 102 8.2.1. Countering Unauthorized Modification Attacks . . . . 22 103 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 23 104 8.2.3. Countering Identity (including Sybil) Attacks . . . . 23 105 8.2.4. Countering Routing Information Replay Attacks . . . . 23 106 8.2.5. Countering Byzantine Routing Information Attacks . . 24 107 8.3. Availability Attack Countermeasures . . . . . . . . . . . 25 108 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing 109 Attacks . . . . . . . . . . . . . . . . . . . . . . . 25 110 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 111 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 112 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 28 113 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 114 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . 29 115 9.1. Confidentiality Features . . . . . . . . . . . . . . . . 30 116 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . 31 117 9.3. Availability Features . . . . . . . . . . . . . . . . . . 31 118 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . 32 119 9.5. Consideration on Matching Application Domain Needs . . . 32 120 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 121 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 35 122 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 123 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 124 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 125 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 126 13.1. Normative References . . . . . . . . . . . . . . . . . . 38 127 13.2. Informative References . . . . . . . . . . . . . . . . . 38 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 130 1. Introduction 132 In recent times, networked electronic devices have found an 133 increasing number of applications in various fields. Yet, for 134 reasons ranging from operational application to economics, these 135 wired and wireless devices are often supplied with minimum physical 136 resources; the constraints include those on computational resources 137 (RAM, clock speed, storage), communication resources (duty cycle, 138 packet size, etc.), but also form factors that may rule out user 139 access interfaces (e.g., the housing of a small stick-on switch), or 140 simply safety considerations (e.g., with gas meters). As a 141 consequence, the resulting networks are more prone to loss of traffic 142 and other vulnerabilities. The proliferation of these low-power and 143 lossy networks (LLNs), however, are drawing efforts to examine and 144 address their potential networking challenges. Securing the 145 establishment and maintenance of network connectivity among these 146 deployed devices becomes one of these key challenges. 148 This document presents a threat analysis for securing Routing Over 149 LLNs (ROLL) through an analysis that starts from the routing basics. 150 The process requires two steps. First, the analysis will be used to 151 identify pertinent security issues. The second step is to identify 152 necessary countermeasures to secure the ROLL protocols. As there are 153 multiple ways to solve the problem and the specific tradeoffs are 154 deployment specific, the specific countermeasure to be used is 155 detailed in applicatbility statements. 157 This document uses [IS07498-2] model, which includes Authentication, 158 Access Control, Data Confidentiality, Data Integrity, and Non- 159 Repudiation but to which Availability is added. 161 All of this document concerns itself with control plane traffic only. 163 2. Terminology 165 This document adopts the terminology defined in [RFC6550], in 166 [RFC4949], and in [I-D.ietf-roll-terminology]. 168 The terms control plane and forwarding plane are used consistently 169 with section 1 of [RFC6192]. 171 3. Considerations on ROLL Security 173 Routing security, in essence, ensures that the routing protocol 174 operates correctly. It entails implementing measures to ensure 175 controlled state changes on devices and network elements, both based 176 on external inputs (received via communications) or internal inputs 177 (physical security of device itself and parameters maintained by the 178 device, including, e.g., clock). State changes would thereby involve 179 not only authorization of injector's actions, authentication of 180 injectors, and potentially confidentiality of routing data, but also 181 proper order of state changes through timeliness, since seriously 182 delayed state changes, such as commands or updates of routing tables, 183 may negatively impact system operation. A security assesment can 184 therefore begin with a focus on the assets [RFC4949] that may be the 185 target of the state changes and the access points in terms of 186 interfaces and protocol exchanges through which such changes may 187 occur. In the case of routing security the focus is directed towards 188 the elements associated with the establishment and maintenance of 189 network connectivity. 191 This section sets the stage for the development of the analysis by 192 applying the systematic approach proposed in [Myagmar2005] to the 193 routing security, while also drawing references from other reviews 194 and assessments found in the literature, particularly, [RFC4593] and 195 [Karlof2003]. The subsequent subsections begin with a focus on the 196 elements of a generic routing process that is used to establish 197 routing assets and points of access to the routing functionality. 198 Next, the [ISO.7498-2.1988] security model is briefly described. 199 Then, consideration is given to issues specific to or amplified in 200 LLNs. This section concludes with the formulation of a set of 201 security objectives for ROLL. 203 3.1. Routing Assets and Points of Access 205 An asset is an important system resource (including information, 206 process, or physical resource), the access to, corruption or loss of 207 which adversely affects the system. In the control plane context, an 208 asset is information about the network, processes used to manage and 209 manipulate this data, and the physical devices on which this data is 210 stored and manipulated. The corruption or loss of these assets may 211 adversely impact the control plane of the network. Within the same 212 context, a point of access is an interface or protocol that 213 facilitates interaction between control plane components. 214 Identifying these assets and points of access will provide a basis 215 for enumerating the attack surface of the control plane. 217 A level-0 data flow diagram [Yourdon1979] is used here to identify 218 the assets and points of access within a generic routing process. 219 The use of a data flow diagram allows for a clear and concise model 220 of the way in which routing nodes interact and process information, 221 and hence provides a context for threats and attacks. The goal of 222 the model is to be as detailed as possible so that corresponding 223 assets, points of access, and process in an individual routing 224 protocol can be readily identified. 226 Figure 1 shows that nodes participating in the routing process 227 transmit messages to discover neighbors and to exchange routing 228 information; routes are then generated and stored, which may be 229 maintained in the form of the protocol forwarding table. The nodes 230 use the derived routes for making forwarding decisions. 232 ................................................... 233 : : 234 : : 235 |Node_i|<------->(Routing Neighbor _________________ : 236 : Discovery)------------>Neighbor Topology : 237 : -------+--------- : 239 : | : 240 |Node_j|<------->(Route/Topology +--------+ : 241 : Exchange) | : 242 : | V ______ : 243 : +---->(Route Generation)--->Routes : 244 : ---+-- : 245 : | : 246 : Routing on a Node Node_k | : 247 ................................................... 248 | 249 |Forwarding | 250 |On Node_l|<-------------------------------------------+ 252 Notation: 254 (Proc) A process Proc 256 ________ 257 topology A structure storing neighbor adjacency (parent/child) 258 -------- 259 ________ 260 routes A structure storing the forwarding information base (FIB) 261 -------- 263 |Node_n| An external entity Node_n 265 -------> Data flow 267 Figure 1: Data Flow Diagram of a Generic Routing Process 269 It is seen from Figure 1 that 271 o Assets include 273 * routing and/or topology information; 275 * route generation process; 277 * communication channel resources (bandwidth); 279 * node resources (computing capacity, memory, and remaining 280 energy); 282 * node identifiers (including node identity and ascribed 283 attributes such as relative or absolute node location). 285 o Points of access include 287 * neighbor discovery; 289 * route/topology exchange; 291 * node physical interfaces (including access to data storage). 293 A focus on the above list of assets and points of access enables a 294 more directed assessment of routing security; for example, it is 295 readily understood that some routing attacks are in the form of 296 attempts to misrepresent routing topology. Indeed, the intention of 297 the security threat analysis is to be comprehensive. Hence, some of 298 the discussion which follows is associated with assets and points of 299 access that are not directly related to routing protocol design but 300 nonetheless provided for reference since they do have direct 301 consequences on the security of routing. 303 3.2. The ISO 7498-2 Security Reference Model 305 At the conceptual level, security within an information system in 306 general and applied to ROLL in particular is concerned with the 307 primary issues of authentication, access control, data 308 confidentiality, data integrity, and non-repudiation. In the context 309 of ROLL 311 Authentication 312 Authentication involves the mutual authentication of the 313 routing peers prior to exchanging route information (i.e., peer 314 authentication) as well as ensuring that the source of the 315 route data is from the peer (i.e., data origin authentication). 316 [RFC5548] points out that LLNs can be drained by 317 unauthenticated peers before configuration. [RFC5673] requires 318 availability of open and untrusted side channels for new 319 joiners, and it requires strong and automated authentication so 320 that networks can automatically accept or reject new joiners. 322 Access Control 323 Access Control provides protection against unauthorized use of 324 the asset, and deals with the authorization of a node. 326 Confidentiality 327 Confidentiality involves the protection of routing information 328 as well as routing neighbor maintenance exchanges so that only 329 authorized and intended network entities may view or access it. 330 Because LLNs are most commonly found on a publicly accessible 331 shared medium, e.g., air or wiring in a building, and sometimes 332 formed ad hoc, confidentiality also extends to the neighbor 333 state and database information within the routing device since 334 the deployment of the network creates the potential for 335 unauthorized access to the physical devices themselves. 337 Integrity 338 Integrity entails the protection of routing information and 339 routing neighbor maintenance exchanges, as well as derived 340 information maintained in the database, from unauthorized 341 modification, insertions, deletions or replays. to be addressed 342 beyond the routing protocol. 344 Non-repudiation 345 Non-repudiation is the assurance that the transmission and/or 346 reception of a message cannot later be denied. The service of 347 non-repudiation applies after-the-fact and thus relies on the 348 logging or other capture of on-going message exchanges and 349 signatures. Applied to routing, non-repudiation is not an 350 issue because it does not apply to routing protocols, which are 351 machine-to-machine protocols. Further, with the LLN 352 application domains as described in [RFC5867] and [RFC5548], 353 proactive measures are much more critical than retrospective 354 protections. Finally, given the significant practical limits 355 to on-going routing transaction logging and storage and 356 individual device digital signature verification for each 357 exchange, non-repudiation in the context of routing is an 358 unsupportable burden that bears no further considered as a ROLL 359 security issue. 361 It is recognized that, besides those security issues captured in the 362 ISO 7498-2 model, availability, is a security requirement: 364 Availability 365 Availability ensures that routing information exchanges and 366 forwarding services need to be available when they are required 367 for the functioning of the serving network. Availability will 368 apply to maintaining efficient and correct operation of routing 369 and neighbor discovery exchanges (including needed information) 370 and forwarding services so as not to impair or limit the 371 network's central traffic flow function 373 It should be emphasized here that for ROLL security the above 374 requirements must be complemented by the proper security policies and 375 enforcement mechanisms to ensure that security objectives are met by 376 a given ROLL implementation. 378 3.3. Issues Specific to or Amplified in LLNs 379 The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have 380 identified specific issues and constraints of routing in LLNs for the 381 urban, industrial, home automation, and building automation 382 application domains, respectively. The following is a list of 383 observations and evaluation of their impact on routing security 384 considerations. 386 Limited energy, memory, and processing node resources 387 As a consequence of these constraints, there is an even more 388 critical need than usual for a careful study of trade-offs on 389 which and what level of security services are to be afforded 390 during the system design process. The chosen security 391 mechanisms also needs to work within these constraints. 392 Synchronization of security states with sleepy nodes is yet 393 another issue. 395 Large scale of rolled out network 396 The possibly numerous nodes to be deployed make manual on-site 397 configuration unlikely. For example, an urban deployment can 398 see several hundreds of thousands of nodes being installed by 399 many installers with a low level of expertise. Nodes may be 400 installed and not activated for many years, and additional 401 nodes may be added later on, which may be from old inventory. 402 The lifetime of the network is measured in decades, and this 403 complicates the operation of key management. 405 Autonomous operations 406 Self-forming and self-organizing are commonly prescribed 407 requirements of LLNs. In other words, a routing protocol 408 designed for LLNs needs to contain elements of ad hoc 409 networking and in most cases cannot rely on manual 410 configuration for initialization or local filtering rules. 411 Network topology/ownership changes, partitioning or merging, as 412 well as node replacement, can all contribute to complicating 413 the operations of key management. 415 Highly directional traffic 416 Some types of LLNs see a high percentage of their total traffic 417 traverse between the nodes and the LLN Border Routers (LBRs) 418 where the LLNs connect to non-LLNs. The special routing status 419 of and the greater volume of traffic near the LBRs have routing 420 security consequences as a higher valued attack target. In 421 fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point 422 (MP2P) traffic represents a majority of the traffic, routing 423 attacks consisting of advertising incorrect preferred routes 424 can cause serious damage. 426 While it might seem that nodes higher up in the cyclic graph 427 (i.e. those with lower rank) should be secured in a stronger 428 fashion, it is not in general easy to predict which nodes will 429 occupy those positions until after deployment. Issues of 430 redundancy and inventory control suggests that any node might 431 wind up in such a sensitive attack position, so all nodes need 432 to be equally secure. 434 In addition, even if it were possible to predict which nodes 435 will occupy positions of lower rank and provision them with 436 stronger security mechanisms, in the absense of a strong 437 authorization model, any node could advertise an incorrect 438 preferred route. 440 Unattended locations and limited physical security 441 Many applications have the nodes deployed in unattended or 442 remote locations; furthermore, the nodes themselves are often 443 built with minimal physical protection. These constraints 444 lower the barrier of accessing the data or security material 445 stored on the nodes through physical means. 447 Support for mobility 448 On the one hand, only a limited number of applications require 449 the support of mobile nodes, e.g., a home LLN that includes 450 nodes on wearable health care devices or an industry LLN that 451 includes nodes on cranes and vehicles. On the other hand, if a 452 routing protocol is indeed used in such applications, it will 453 clearly need to have corresponding security mechanisms. 455 Additionally nodes may appear to move from one side of a wall 456 to another without any actual motion involved, the result of 457 changes to electromagnetic properties, such as opening and 458 closing of a metal door. 460 Support for multicast and anycast 461 Support for multicast and anycast is called out chiefly for 462 large-scale networks. Since application of these routing 463 mechanisms in autonomous operations of many nodes is new, the 464 consequence on security requires careful consideration. 466 The above list considers how an LLN's physical constraints, size, 467 operations, and variety of application areas may impact security. 468 However, it is the combinations of these factors that particularly 469 stress the security concerns. For instance, securing routing for a 470 large number of autonomous devices that are left in unattended 471 locations with limited physical security presents challenges that are 472 not found in the common circumstance of administered networked 473 routers. The following subsection sets up the security objectives 474 for the routing protocol designed by the ROLL WG. 476 3.4. ROLL Security Objectives 478 This subsection applies the ISO 7498-2 model to routing assets and 479 access points, taking into account the LLN issues, to develop a set 480 of ROLL security objectives. 482 Since the fundamental function of a routing protocol is to build 483 routes for forwarding packets, it is essential to ensure that: 485 o routing/topology information iintegrity remains intact during 486 transfer and in storage; 488 o routing/topology information is used by authorized entities; 490 o routing/topology information is available when needed. 492 In conjunction, it is necessary to be assured that 494 o authorized peers authenticate themselves during the routing 495 neighbor discovery process; 497 o the routing/topology information received is generated according 498 to the protocol design. 500 However, when trust cannot be fully vested through authentication of 501 the principals alone, i.e., concerns of insider attack, assurance of 502 the truthfulness and timeliness of the received routing/topology 503 information is necessary. With regard to confidentiality, protecting 504 the routing/topology information from unauthorized exposure may be 505 desirable in certain cases but is in itself less pertinent in general 506 to the routing function. 508 One of the main problems of synchronizing security states of sleepy 509 nodes, as listed in the last subsection, lies in difficulties in 510 authentication; these nodes may not have received in time the most 511 recent update of security material. Similarly, the issues of minimal 512 manual configuration, prolonged rollout and delayed addition of 513 nodes, and network topology changes also complicate key management. 515 Hence, routing in LLNs needs to bootstrap the authentication process 516 and allow for flexible expiration scheme of authentication 517 credentials. 519 The vulnerability brought forth by some special-function nodes, e.g., 520 LBRs, requires the assurance, particularly in a security context, 522 o of the availability of communication channels and node resources; 524 o that the neighbor discovery process operates without undermining 525 routing availability. 527 There are other factors which are not part of a ROLL protocol but 528 directly affecting its function. These factors include weaker 529 barrier of accessing the data or security material stored on the 530 nodes through physical means; therefore, the internal and external 531 interfaces of a node need to be adequate for guarding the integrity, 532 and possibly the confidentiality, of stored information, as well as 533 the integrity of routing and route generation processes. 535 Each individual system's use and environment will dictate how the 536 above objectives are applied, including the choices of security 537 services as well as the strengths of the mechanisms that must be 538 implemented. The next two sections take a closer look at how the 539 ROLL security objectives may be compromised and how those potential 540 compromises can be countered. 542 4. Threat Sources 544 [RFC4593] provides a detailed review of the threat sources: outsiders 545 and byzantine. ROLL has the same threat sources. 547 5. Threats and Attacks 549 This section outlines general categories of threats under the ISO 550 7498-2 model and highlights the specific attacks in each of these 551 categories for ROLL. As defined in [RFC4949], a threat is "a 552 potential for violation of security, which exists when there is a 553 circumstance, capability, action, or event that could breach security 554 and cause harm." 556 An attack is "an assault on system security that derives from an 557 intelligent threat, i.e., an intelligent act that is a deliberate 558 attempt (especially in the sense of a method or technique) to evade 559 security services and violate the security policy of a system." 561 The subsequent subsections consider the threats and the attacks that 562 can cause security breaches under the ISO 7498-2 model to the routing 563 assets and via the routing points of access identified in 564 Section 3.1. The assessment steps through the security concerns of 565 each routing asset and looks at the attacks that can exploit routing 566 points of access. The threats and attacks identified are based on 567 the routing model analysis and associated review of the existing 568 literature. The source of the attacks is assumed to be from either 569 inside or outside attackers. The capability these attackes may be 570 limited to node-equivalent, but also to more sophisticated computing 571 platforms. 573 5.1. Threats due to failures to Authenticate 575 5.1.1. Node Impersonation 577 If an attacker can join a network with any identify, then it may be 578 able to assume the role of a legitimate (and existing node). It may 579 be able to report false readings (in metering applications), or 580 provide inappropriate control messages (in control systems involving 581 actuators) if the security of the application is leveraged from the 582 security of the routing system. 584 In other systems where there is separate application layer security, 585 the ability to impersonate a node would permit an attacker to direct 586 traffic to itself, which facilitates on-path attacks including 587 replaying, delaying, or duplicating control messages. 589 5.1.2. Dummy Node 591 If an attacker can join a network with any identify, then it can 592 pretend to be a legitimate node, receiving any service legitimate 593 nodes receive. It may also be able to report false readings (in 594 metering applications), or provide inappropriate authorizations (in 595 control systems involving actuators), or perform any other attacks 596 that are facilitated by being able to direct traffic towards itself. 598 5.1.3. Node Resource Spam 600 If an attacker can join a network with any identify, then it can 601 continously do so, draining down the resources of the network to 602 store identity and routing information, potentionally forcing 603 legitimate nodes of the network. 605 5.2. Threats and Attacks on Confidentiality 607 The assessment in Section 3.2 indicates that there are threat actions 608 against the confidentiality of routing information at all points of 609 access. The confidentiality threat consequences is disclosure, see 610 Section 3.1.2 of [RFC4593]. For ROLL this is the disclosure of 611 routing information either by evesdropping on the communication 612 exchanges between routing nodes or by direct access of node's 613 information. 615 5.2.1. Routing Exchange Exposure 617 Routing exchanges include both routing information as well as 618 information associated with the establishment and maintenance of 619 neighbor state information. As indicated in Section 3.1, the 620 associated routing information assets may also include device 621 specific resource information, such as memory, remaining power, etc., 622 that may be metrics of the routing protocol. 624 The routing exchanges will contain reachability information, which 625 would identify the relative importance of different nodes in the 626 network. Nodes higher up in the DODAG, to which more streams of 627 information flow, would be more interesting targets for other 628 attacks, and routing exchange exposures can identify them. 630 5.2.2. Routing Information (Routes and Network Topology) Exposure 632 Routes (which may be maintained in the form of the protocol 633 forwarding table) and neighbor topology information are the products 634 of the routing process that are stored within the node device 635 databases. 637 The exposure of this information will allow attachers to gain direct 638 access to the configuration and connectivity of the network thereby 639 exposing routing to targeted attacks on key nodes or links. Since 640 routes and neighbor topology information is stored within the node 641 device, threats or attacks on the confidentiality of the information 642 will apply to the physical device including specified and unspecified 643 internal and external interfaces. 645 The forms of attack that allow unauthorized access or disclosure of 646 the routing information (other than occurring through explicit node 647 exchanges) will include: 649 o Physical device compromise; 651 o Remote device access attacks (including those occurring through 652 remote network management or software/field upgrade interfaces). 654 Both of these attack vectors are considered a device specific issue, 655 and are out of scope for the RPL protocol to defend against. In some 656 applications, physical device compromise may be a real threat and it 657 may be necessary to provide for other devices to react quickly to 658 exclude a compromised device. 660 6. Threats and Attacks on Integrity 662 The assessment in Section 3.2 indicates that information and identity 663 assets are exposed to integrity threats from all points of access. 664 In other words, the integrity threat space is defined by the 665 potential for exploitation introduced by access to assets available 666 through routing exchanges and the on-device storage. 668 6.1. Routing Information Manipulation 670 Manipulation of routing information that range from neighbor states 671 to derived routes will allow unauthorized sources to influence the 672 operation and convergence of the routing protocols and ultimately 673 impact the forwarding decisions made in the network. 675 Manipulation of topology and reachability information will allow 676 unauthorized sources to influence the nodes with which routing 677 information is exchanged and updated. The consequence of 678 manipulating routing exchanges can thus lead to sub-optimality and 679 fragmentation or partitioning of the network by restricting the 680 universe of routers with which associations can be established and 681 maintained. 683 A sub-optimal network may use too much power and/or may congest some 684 routes leading to premature failure of a node, and a denial of 685 service on the entire network. 687 In addition, being able to attract network traffic can make a 688 blackhole attack more damaging. 690 The forms of attack that allow manipulation to compromise the content 691 and validity of routing information include 693 o Falsification, including overclaiming and misclaiming; 695 o Routing information replay; 697 o Byzantine (internal) attacks that permit corruption of routing 698 information in the node even where the node continues to be a 699 validated entity within the network (see, for example, [RFC4593] 700 for further discussions on Byzantine attacks); 702 o Physical device compromise or remote device access attacks. 704 6.2. Node Identity Misappropriation 706 Falsification or misappropriation of node identity between routing 707 participants opens the door for other attacks; it can also cause 708 incorrect routing relationships to form and/or topologies to emerge. 709 Routing attacks may also be mounted through less sophisticated node 710 identity misappropriation in which the valid information broadcast or 711 exchanged by a node is replayed without modification. The receipt of 712 seemingly valid information that is however no longer current can 713 result in routing disruption, and instability (including failure to 714 converge). Without measures to authenticate the routing participants 715 and to ensure the freshness and validity of the received information 716 the protocol operation can be compromised. The forms of attack that 717 misuse node identity include 719 o Identity attacks, including Sybil attacks in which a malicious 720 node illegitimately assumes multiple identities; 722 o Routing information replay. 724 7. Threats and Attacks on Availability 726 The assessment in Section 3.2 indicates that the process and 727 resources assets are exposed to threats against availability; attacks 728 in this category may exploit directly or indirectly information 729 exchange or forwarding (see [RFC4732] for a general discussion). 731 7.1. Routing Exchange Interference or Disruption 733 Interference is the threat action and disruption is threat 734 consequence that allows attackers to influence the operation and 735 convergence of the routing protocols by impeding the routing 736 information exchange. 738 The forms of attack that allow interference or disruption of routing 739 exchange include: 741 o Routing information replay; 743 o ACK spoofing; 745 o Overload attacks. (Section 8.3.2) 747 In addition, attacks may also be directly conducted at the physical 748 layer in the form of jamming or interfering. 750 7.2. Network Traffic Forwarding Disruption 751 The disruption of the network traffic forwarding capability will 752 undermine the central function of network routers and the ability to 753 handle user traffic. This affects the availability of the network 754 because of the potential to impair the primary capability of the 755 network. 757 In addition to physical layer obstructions, the forms of attack that 758 allows disruption of network traffic forwarding include [Karlof2003] 760 o Selective forwarding attacks; 762 |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| 764 (a) Selective Forwarding 766 Figure 2: Selective Forwarding 768 o Wormhole attacks; 770 |Node_1|-------------Unreachable---------x|Node_2| 771 | ^ 772 | Private Link | 773 '-->|Attacker_1|===========>|Attacker_2|--' 775 (b) Wormhole 777 Figure 3: Wormhole Attacks 779 o Sinkhole attacks. 781 |Node_1| |Node_4| 782 | | 783 `--------. | 784 Falsify as \ | 785 Good Link \ | | 786 To Node_5 \ | | 787 \ V V 788 |Node_2|-->|Attacker|--Not Forwarded---x|Node_5| 789 ^ ^ \ 790 | | \ Falsify as 791 | | \Good Link 792 / | To Node_5 793 ,-------' | 794 | | 796 |Node_3| |Node_i| 798 (c) Sinkhole 800 Figure 4: Selective Forwarding, Wormhole, and Sinkhole Attacks 802 These attacks are generally done to both control plane and forwarding 803 plane traffic. A system that prevents control plane traffic (RPL 804 messages) from being diverted in these ways will also prevent actual 805 data from being diverted. 807 7.3. Communications Resource Disruption 809 Attacks mounted against the communication channel resource assets 810 needed by the routing protocol can be used as a means of disrupting 811 its operation. However, while various forms of Denial of Service 812 (DoS) attacks on the underlying transport subsystem will affect 813 routing protocol exchanges and operation (for example physical layer 814 RF jamming in a wireless network or link layer attacks), these 815 attacks cannot be countered by the routing protocol. As such, the 816 threats to the underlying transport network that supports routing is 817 considered beyond the scope of the current document. Nonetheless, 818 attacks on the subsystem will affect routing operation and so must be 819 directly addressed within the underlying subsystem and its 820 implemented protocol layers. 822 7.4. Node Resource Exhaustion 824 A potential threat consequence can arise from attempts to overload 825 the node resource asset by initiating exchanges that can lead to the 826 exhaustion of processing, memory, or energy resources. The 827 establishment and maintenance of routing neighbors opens the routing 828 process to engagement and potential acceptance of multiple 829 neighboring peers. Association information must be stored for each 830 peer entity and for the wireless network operation provisions made to 831 periodically update and reassess the associations. An introduced 832 proliferation of apparent routing peers can therefore have a negative 833 impact on node resources. 835 Node resources may also be unduly consumed by attackers attempting 836 uncontrolled topology peering or routing exchanges, routing replays, 837 or the generating of other data traffic floods. Beyond the 838 disruption of communications channel resources, these consequences 839 may be able to exhaust node resources only where the engagements are 840 able to proceed with the peer routing entities. Routing operation 841 and network forwarding functions can thus be adversely impacted by 842 node resources exhaustion that stems from attacks that include: 844 o Identity (including Sybil) attacks; 846 o Routing information replay attacks; 848 o HELLO flood attacks; 850 o Overload attacks. (Section 8.3.2) 852 8. Countermeasures 854 By recognizing the characteristics of LLNs that may impact routing, 855 this analysis provides the basis for developing capabilities within 856 ROLL protocols to deter the identified attacks and mitigate the 857 threats. The following subsections consider such countermeasures by 858 grouping the attacks according to the classification of the ISO 859 7498-2 model so that associations with the necessary security 860 services are more readily visible. However, the considerations here 861 are more systematic than confined to means available only within 862 routing; the next section will then distill and make recommendations 863 appropriate for a secured ROLL protocol. 865 8.1. Confidentiality Attack Countermeasures 867 Attacks to disclosure routing information may be mounted at the level 868 of the routing information assets, at the points of access associated 869 with routing exchanges between nodes, or through device interface 870 access. To gain access to routing/topology information, the attacker 871 may rely on a compromised node that deliberately exposes the 872 information during the routing exchange process, may rely on passive 873 wiretapping or traffic analysis, or may attempt access through a 874 component or device interface of a tampered routing node. 876 8.1.1. Countering Deliberate Exposure Attacks 878 A deliberate exposure attack is one in which an entity that is party 879 to the routing process or topology exchange allows the routing/ 880 topology information or generated route information to be exposed to 881 an unauthorized entity. 883 A prerequisite to countering this attack is to ensure that the 884 communicating nodes are authenticated prior to data encryption 885 applied in the routing exchange. Authentication ensures that the 886 nodes are who they claim to be even though it does not provide an 887 indication of whether the node has been compromised. 889 To mitigate the risk of deliberate exposure, the process that 890 communicating nodes use to establish session keys must be peer-to- 891 peer (i.e., between the routing initiating and responding nodes). 893 This helps ensure that neither node is exchaning routing information 894 with another peer without the knowledge of both communicating 895 peerscan. For a deliberate exposure attack to succeed, the comprised 896 node will need to more overt and take independent actions in order to 897 disclose the routing information to 3rd party. 899 Note that the same measures which apply to securing routing/topology 900 exchanges between operational nodes must also extend to field tools 901 and other devices used in a deployed network where such devices can 902 be configured to participate in routing exchanges. 904 8.1.2. Countering Passive Wiretapping Attacks 906 A passive wiretap attack seeks to breach routing confidentiality 907 through passive, direct analysis and processing of the information 908 exchanges between nodes. 910 Passive wiretap attacks can be directly countered through the use of 911 data encryption for all routing exchanges. Only when a validated and 912 authenticated node association is completed will routing exchange be 913 allowed to proceed using established session keys and an agreed 914 encryption algorithm. The strength of the encryption algorithm and 915 session key sizes will determine the minimum requirement for an 916 attacker mounting this passive security attack. The possibility of 917 incorporating options for security level and algorithms is further 918 considered in Section 9.5. Because of the resource constraints of 919 LLN devices, symmetric (private) key encryption will provide the best 920 trade-off in terms of node and channel resource overhead and the 921 level of security achieved. This will of course not preclude the use 922 of asymmetric (public) key encryption during the session key 923 establishment phase. 925 As with the key establishment process, data encryption must include 926 an authentication prerequisite to ensure that each node is 927 implementing a level of security that prevents deliberate or 928 inadvertent exposure. The authenticated key establishment will 929 ensure that confidentiality is not compromised by providing the 930 information to an unauthorized entity (see also [Huang2003]). 932 Based on the current state of the art, a minimum 128-bit key length 933 should be applied where robust confidentiality is demanded for 934 routing protection. This session key shall be applied in conjunction 935 with an encryption algorithm that has been publicly vetted and where 936 applicable approved for the level of security desired. Algorithms 937 such as the Advanced Encryption Standard (AES) [FIPS197], adopted by 938 the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the 939 3GPP 3rd generation wireless mobile consortium, are examples of 940 symmetric-key algorithms capable of ensuring robust confidentiality 941 for routing exchanges. The key length, algorithm and mode of 942 operation will be selected as part of the overall security trade-off 943 that also achieves a balance with the level of confidentiality 944 afforded by the physical device in protecting the routing assets. 946 As with any encryption algorithm, the use of ciphering 947 synchronization parameters and limitations to the usage duration of 948 established keys should be part of the security specification to 949 reduce the potential for brute force analysis. 951 8.1.3. Countering Traffic Analysis 953 Traffic analysis provides an indirect means of subverting 954 confidentiality and gaining access to routing information by allowing 955 an attacker to indirectly map the connectivity or flow patterns 956 (including link-load) of the network from which other attacks can be 957 mounted. The traffic analysis attack on an LLN, especially one 958 founded on shared medium, is passive and relies on the ability to 959 read the immutable source/destination layer-3 routing information 960 that must remain unencrypted to permit network routing. 962 One way in which passive traffic analysis attacks can be muted is 963 through the support of load balancing that allows traffic to a given 964 destination to be sent along diverse routing paths. Where the 965 routing protocol supports load balancing along multiple links at each 966 node, the number of routing permutations in a wide area network 967 surges thus increasing the cost of traffic analysis. ROLL does not 968 generally support multi-path routing within a single DODAG. Multiple 969 DODAGs are supported in the protocol, but few deployments will have 970 space for more than half a dozen, and there are at present no clear 971 ways to multiplex traffic for a single application across multiple 972 DODAGs. 974 Another approach to countering passive traffic analysis could be for 975 nodes to maintain constant amount of traffic to different 976 destinations through the generation of arbitrary traffic flows; the 977 drawback of course would be the consequent overhead. 979 The only means of fully countering a traffic analysis attack is 980 through the use of tunneling (encapsulation) where encryption is 981 applied across the entirety of the original packet source/destination 982 addresses. Deployments which use layer-2 security that includes 983 encryption already do this for all traffic. 985 8.1.4. Countering Remote Device Access Attacks 987 Where LLN nodes are deployed in the field, measures are introduced to 988 allow for remote retrieval of routing data and for software or field 989 upgrades. These paths create the potential for a device to be 990 remotely accessed across the network or through a provided field 991 tool. In the case of network management a node can be directly 992 requested to provide routing tables and neighbor information. 994 To ensure confidentiality of the node routing information against 995 attacks through remote access, any local or remote device requesting 996 routing information must be authenticated to ensure authorized 997 access. Since remote access is not invoked as part of a routing 998 protocol security of routing information stored on the node against 999 remote access will not be addressable as part of the routing 1000 protocol. 1002 8.2. Integrity Attack Countermeasures 1004 Integrity attack countermeasures address routing information 1005 manipulation, as well as node identity and routing information 1006 misuse. Manipulation can occur in the form of falsification attack 1007 and physical compromise. To be effective, the following development 1008 considers the two aspects of falsification, namely, the unauthorized 1009 modifications and the overclaiming and misclaiming content. The 1010 countering of physical compromise was considered in the previous 1011 section and is not repeated here. With regard to misuse, there are 1012 two types of attacks to be deterred, identity attacks and replay 1013 attacks. 1015 8.2.1. Countering Unauthorized Modification Attacks 1017 Unauthorized modifications may occur in the form of altering the 1018 message being transferred or the data stored. Therefore, it is 1019 necessary to ensure that only authorized nodes can change the portion 1020 of the information that is allowed to be mutable, while the integrity 1021 of the rest of the information is protected, e.g., through well- 1022 studied cryptographic mechanisms. 1024 Unauthorized modifications may also occur in the form of insertion or 1025 deletion of messages during protocol changes. Therefore, the 1026 protocol needs to ensure the integrity of the sequence of the 1027 exchange sequence. 1029 The countermeasure to unauthorized modifications needs to: 1031 o implement access control on storage; 1033 o provide data integrity service to transferred messages and stored 1034 data; 1036 o include sequence number under integrity protection. 1038 8.2.2. Countering Overclaiming and Misclaiming Attacks 1040 Both overclaiming and misclaiming aim to introduce false routes or 1041 topology that would not be generated by the network otherwise, while 1042 there are not necessarily unauthorized modifications to the routing 1043 messages or information. The requisite for a counter is the 1044 capability to determine unreasonable routes or topology. 1046 The counter to overclaiming and misclaiming may employ: 1048 o comparison with historical routing/topology data; 1050 o designs which restrict realizable network topologies. 1052 8.2.3. Countering Identity (including Sybil) Attacks 1054 Identity attacks, sometimes simply called spoofing, seek to gain or 1055 damage assets whose access is controlled through identity. In 1056 routing, an identity attacker can illegitimately participate in 1057 routing exchanges, distribute false routing information, or cause an 1058 invalid outcome of a routing process. 1060 A perpetrator of Sybil attacks assumes multiple identities. The 1061 result is not only an amplification of the damage to routing, but 1062 extension to new areas, e.g., where geographic distribution is 1063 explicitly or implicitly an asset to an application running on the 1064 LLN, for example, the LBR in a P2MP or MP2P LLN. 1066 8.2.4. Countering Routing Information Replay Attacks 1068 In many routing protocols, message replay can result in false 1069 topology and/or routes. This is often counted with some kind of 1070 counter to ensure the freshness of the message. Replay of a current, 1071 literal RPL message are in general idempotent to the topology. An 1072 older (lower DODAGVersionNumber) message, if replayed would be 1073 rejected as being stale. The trickle algorithm further dampens the 1074 affect of any such replay, as if the message was current, then it 1075 would contain the same information as before, and it would cause no 1076 network changes. 1078 Replays may well occur in some radio technologies (not very likely, 1079 802.15.4) as a result of echos or reflections, and so some replays 1080 must be assumed to occur naturally. 1082 Note that for there to be no affect at all, the replay must be done 1083 with the same apparent power for all nodes receiving the replay. A 1084 change in apparent power might change the metrics through changes to 1085 the ETX and therefore might affect the routing even though the 1086 contents of the packet were never changed. Any replay which appears 1087 to be different should be analyzed as a Selective Forwarding Attack, 1088 Sinkhole Attack or Wormhole Attack. 1090 8.2.5. Countering Byzantine Routing Information Attacks 1092 Where a node is captured or compromised but continues to operate for 1093 a period with valid network security credentials, the potential 1094 exists for routing information to be manipulated. This compromise of 1095 the routing information could thus exist in spite of security 1096 countermeasures that operate between the peer routing devices. 1098 Consistent with the end-to-end principle of communications, such an 1099 attack can only be fully addressed through measures operating 1100 directly between the routing entities themselves or by means of 1101 external entities able to access and independently analyze the 1102 routing information. Verification of the authenticity and liveliness 1103 of the routing entities can therefore only provide a limited counter 1104 against internal (Byzantine) node attacks. 1106 For link state routing protocols where information is flooded with, 1107 for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC1142]), 1108 countermeasures can be directly applied by the routing entities 1109 through the processing and comparison of link state information 1110 received from different peers. By comparing the link information 1111 from multiple sources decisions can be made by a routing node or 1112 external entity with regard to routing information validity; see 1113 Chapter 2 of [Perlman1988] for a discussion on flooding attacks. 1115 For distance vector protocols where information is aggregated at each 1116 routing node it is not possible for nodes to directly detect 1117 Byzantine information manipulation attacks from the routing 1118 information exchange. In such cases, the routing protocol must 1119 include and support indirect communications exchanges between non- 1120 adjacent routing peers to provide a secondary channel for performing 1121 routing information validation. S-RIP [Wan2004] is an example of the 1122 implementation of this type of dedicated routing protocol security 1123 where the correctness of aggregate distance vector information can 1124 only be validated by initiating confirmation exchanges directly 1125 between nodes that are not routing neighbors. 1127 Alternatively, an entity external to the routing protocol would be 1128 required to collect and audit routing information exchanges to detect 1129 the Byzantine attack. In the context of the current security 1130 analysis, any protection against Byzantine routing information 1131 attacks will need to be directly included within the mechanisms of 1132 the ROLL routing protocol. 1134 8.3. Availability Attack Countermeasures 1136 As alluded to before, availability requires that routing information 1137 exchanges and forwarding mechanisms be available when needed so as to 1138 guarantee proper functioning of the network. This may, e.g., include 1139 the correct operation of routing information and neighbor state 1140 information exchanges, among others. We will highlight the key 1141 features of the security threats along with typical countermeasures 1142 to prevent or at least mitigate them. We will also note that an 1143 availability attack may be facilitated by an identity attack as well 1144 as a replay attack, as was addressed in Section 8.2.3 and 1145 Section 8.2.4, respectively. 1147 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 1149 HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing 1150 attacks are different but highly related forms of attacking an LLN. 1151 They essentially lead nodes to believe that suitable routes are 1152 available even though they are not and hence constitute a serious 1153 availability attack. 1155 A HELLO attack mounted against RPL would involve sending out (or 1156 replaying) DIO messages by the attacker. Lower power LLN nodes might 1157 then attempt to join the DODAG at a lower rank than they would 1158 otherwise. 1160 The most effective method from [I-D.suhopark-hello-wsn] is the verify 1161 bidirectionality. A number of layer-2 links are arranged in 1162 controller/spoke arrangements, and continuously are validating 1163 connectivity at layer 2. 1165 In addition, in order to calculate metrics, the ETX must be computed, 1166 and this involves, in general, sending a number of messages between 1167 nodes which are believed to be adjacent. 1168 [I-D.kelsey-intarea-mesh-link-establishment] is one such protocol. 1170 In order to join the DODAG, a DAO message is sent upwards. In RPL 1171 the DAO is acknowledged by the DAO-ACK message. This clearly checks 1172 bidirectionality at the control plane. 1174 As discussed in section 5.1, [I-D.suhopark-hello-wsn] a receiver with 1175 a sensitive receiver could well hear the DAOs, and even send DAO-ACKs 1176 as well. Such a node is a form of WormHole attack. 1178 These attacks are also all easily defended against using either 1179 layer-2 or layer-3 authentication. Such an attack could only be made 1180 against a completely open network (such as might be used for 1181 provisioning new nodes), or by a compromised node. 1183 8.3.2. Countering Overload Attacks 1185 Overload attacks are a form of DoS attack in that a malicious node 1186 overloads the network with irrelevant traffic, thereby draining the 1187 nodes' energy store more quickly, when the nodes rely on batteries or 1188 energy scavenging. It thus significantly shortens the lifetime of 1189 networks of energy-constrained nodes and constitutes another serious 1190 availability attack. 1192 With energy being one of the most precious assets of LLNs, targeting 1193 its availability is a fairly obvious attack. Another way of 1194 depleting the energy of an LLN node is to have the malicious node 1195 overload the network with irrelevant traffic. This impacts 1196 availability since certain routes get congested which: 1198 o renders them useless for affected nodes and data can hence not be 1199 delivered; 1201 o makes routes longer as shortest path algorithms work with the 1202 congested network; 1204 o depletes battery and energy scavenging nodes more quickly and thus 1205 shortens the network's availability at large. 1207 Overload attacks can be countered by deploying a series of mutually 1208 non-exclusive security measures: 1210 o introduce quotas on the traffic rate each node is allowed to send; 1212 o isolate nodes which send traffic above a certain threshold based 1213 on system operation characteristics; 1215 o allow only trusted data to be received and forwarded. 1217 As for the first one, a simple approach to minimize the harmful 1218 impact of an overload attack is to introduce traffic quotas. This 1219 prevents a malicious node from injecting a large amount of traffic 1220 into the network, even though it does not prevent said node from 1221 injecting irrelevant traffic at all. Another method is to isolate 1222 nodes from the network at the network layer once it has been detected 1223 that more traffic is injected into the network than allowed by a 1224 prior set or dynamically adjusted threshold. Finally, if 1225 communication is sufficiently secured, only trusted nodes can receive 1226 and forward traffic which also lowers the risk of an overload attack. 1228 Receiving nodes that validate signatures and sending nodes that 1229 encrypt messages need to be cautious of cryptographic processing 1230 usage when validating signatures and encrypting messages. Where 1231 feasible, certificates should be validated prior to use of the 1232 associated keys to counter potential resource overloading attacks. 1233 The associated design decision needs to also consider that the 1234 validation process requires resources and thus itself could be 1235 exploited for attacks. Alternatively, resource management limits can 1236 be placed on routing security processing events (see the comment in 1237 Section 6, paragraph 4, of [RFC5751]). 1239 8.3.3. Countering Selective Forwarding Attacks 1241 Selective forwarding attacks are a form of DoS attack which impacts 1242 the availability of the generated routing paths. 1244 A selective forwarding attack may be done by a node involved with the 1245 routing process, or it may be done by what otherwise appears to be a 1246 passive antenna or other RF feature or device, but is in fact an 1247 active (and selective) device. An RF antenna/repeater which is not 1248 selective, is not a threat. 1250 An insider malicious node basically blends neatly in with the network 1251 but then may decide to forward and/or manipulate certain packets. If 1252 all packets are dropped, then this attacker is also often referred to 1253 as a "black hole". Such a form of attack is particularly dangerous 1254 if coupled with sinkhole attacks since inherently a large amount of 1255 traffic is attracted to the malicious node and thereby causing 1256 significant damage. In a shared medium, an outside malicious node 1257 would selectively jam overheard data flows, where the thus caused 1258 collisions incur selective forwarding. 1260 Selective Forwarding attacks can be countered by deploying a series 1261 of mutually non-exclusive security measures: 1263 o multipath routing of the same message over disjoint paths; 1265 o dynamically selecting the next hop from a set of candidates. 1267 The first measure basically guarantees that if a message gets lost on 1268 a particular routing path due to a malicious selective forwarding 1269 attack, there will be another route which successfully delivers the 1270 data. Such a method is inherently suboptimal from an energy 1271 consumption point of view; it is also suboptimal from a network 1272 utilization perspective. The second method basically involves a 1273 constantly changing routing topology in that next-hop routers are 1274 chosen from a dynamic set in the hope that the number of malicious 1275 nodes in this set is negligible. A routing protocol that allows for 1276 disjoint routing paths may also be useful. 1278 8.3.4. Countering Sinkhole Attacks 1280 In sinkhole attacks, the malicious node manages to attract a lot of 1281 traffic mainly by advertising the availability of high-quality links 1282 even though there are none [Karlof2003]. It hence constitutes a 1283 serious attack on availability. 1285 The malicious node creates a sinkhole by attracting a large amount 1286 of, if not all, traffic from surrounding neighbors by advertising in 1287 and outwards links of superior quality. Affected nodes hence eagerly 1288 route their traffic via the malicious node which, if coupled with 1289 other attacks such as selective forwarding, may lead to serious 1290 availability and security breaches. Such an attack can only be 1291 executed by an inside malicious node and is generally very difficult 1292 to detect. An ongoing attack has a profound impact on the network 1293 topology and essentially becomes a problem of flow control. 1295 Sinkhole attacks can be countered by deploying a series of mutually 1296 non-exclusive security measures: 1298 o use geographical insights for flow control; 1300 o isolate nodes which receive traffic above a certain threshold; 1302 o dynamically pick up next hop from set of candidates; 1304 o allow only trusted data to be received and forwarded. 1306 Some LLNs may provide for geolocation services, often derived from 1307 solving triangulation equations from radio delay calculations, such 1308 calculations could in theory be subverted by a sinkhole that 1309 transmitted at precisely the right power in a node to node fashion. 1311 While geographic knowledge could help assure that traffic always went 1312 in the physical direction desired, it would not assure that the 1313 traffic was taking the most efficient route, as the lowest cost real 1314 route might be match the physical topology; such as when different 1315 parts of an LLN are connected by high-speed wired networks. 1317 8.3.5. Countering Wormhole Attacks 1319 In wormhole attacks at least two malicious nodes claim to have a 1320 short path between themselves [Karlof2003]. This changes the 1321 availability of certain routing paths and hence constitutes a serious 1322 security breach. 1324 Essentially, two malicious insider nodes use another, more powerful, 1325 transmitter to communicate with each other and thereby distort the 1326 would-be-agreed routing path. This distortion could involve 1327 shortcutting and hence paralyzing a large part of the network; it 1328 could also involve tunneling the information to another region of the 1329 network where there are, e.g., more malicious nodes available to aid 1330 the intrusion or where messages are replayed, etc. 1332 In conjunction with selective forwarding, wormhole attacks can create 1333 race conditions which impact topology maintenance, routing protocols 1334 as well as any security suits built on "time of check" and "time of 1335 use". 1337 A pure Wormhole attack is nearly impossible to detect. A wormhole 1338 which is used in order to subsequently mount another kind of attack 1339 would be defeated by defeating the other attack. A perfect wormhole, 1340 in which there is nothing adverse that occurs to the traffic, would 1341 be difficult to call an attack. The worst thing that a benign 1342 wormhole can do in such a situation is to cease to operate (become 1343 unstable), causing the network to have to recalculate routes. 1345 A highly unstable wormhole is no different than a radio opaque (i.e. 1346 metal) door that opens and closes a lot. RPL includes hystersis in 1347 its objective functions [RFC6719] in an attempt to deal with frequent 1348 changes to the ETX between nodes. 1350 9. ROLL Security Features 1352 The assessments and analysis in Section 5 examined all areas of 1353 threats and attacks that could impact routing, and the 1354 countermeasures presented in Section 8 were reached without confining 1355 the consideration to means only available to routing. This section 1356 puts the results into perspective and provides a framework for 1357 addressing the derived set of security objectives that must be met by 1358 the routing protocol(s) specified by the ROLL Working Group. It 1359 bears emphasizing that the target here is a generic, universal form 1360 of the protocol(s) specified and the normative keywords are mainly to 1361 convey the relative level of importance or urgency of the features 1362 specified. 1364 In this view, 'MUST' is used to define the requirements that are 1365 specific to the routing protocol and that are essential for an LLN 1366 routing protocol to ensure that routing operation can be maintained. 1367 Adherence to MUST requirements is needed to directly counter attacks 1368 that can affect the routing operation (such as those that can impact 1369 maintained or derived routing/forwarding tables). 'SHOULD' is used 1370 to define requirements that counter indirect routing attacks where 1371 such attacks do not of themselves affect routing but can assist an 1372 attacker in focusing its attack resources to impact network operation 1373 (such as DoS targeting of key forwarding nodes). 'MAY' covers 1374 optional requirements that can further enhance security by increasing 1375 the space over which an attacker must operate or the resources that 1376 must be applied. While in support of routing security, where 1377 appropriate, these requirements may also be addressed beyond the 1378 network routing protocol at other system communications layers. 1380 The first part of this section, Section 9.1 to Section 9.3, is a 1381 prescription of ROLL security features of measures that can be 1382 addressed as part of the routing protocol itself. As routing is one 1383 component of an LLN system, the actual strength of the security 1384 services afforded to it should be made to conform to each system's 1385 security policy; how a design may address the needs of the urban, 1386 industrial, home automation, and building automation application 1387 domains also needs to be considered. The second part of this 1388 section, Section 9.4 and Section 9.5, discusses system security 1389 aspects that may impact routing but that also require considerations 1390 beyond the routing protocol, as well as potential approaches. 1392 If an LLN employs multicast and/or anycast, these alternative 1393 communications modes MUST be secured with the same routing security 1394 services specified in this section. Furthermore, irrespective of the 1395 modes of communication, nodes MUST provide adequate physical tamper 1396 resistance commensurate with the particular application domain 1397 environment to ensure the confidentiality, integrity, and 1398 availability of stored routing information. 1400 9.1. Confidentiality Features 1402 With regard to confidentiality, protecting the routing/topology 1403 information from unauthorized disclosure is not directly essential to 1404 maintaining the routing function. Breaches of confidentiality may 1405 lead to other attacks or the focusing of an attacker's resources (see 1406 Section 5.2) but does not of itself directly undermine the operation 1407 of the routing function. However, to protect against, and reduce 1408 consequences from other more direct attacks, routing information 1409 should be protected. Thus, a secured ROLL protocol: 1411 o MUST implement payload encryption; 1413 o MAY provide tunneling; 1415 o MAY provide load balancing. 1417 Where confidentiality is incorporated into the routing exchanges, 1418 encryption algorithms and key lengths need to be specified in 1419 accordance with the level of protection dictated by the routing 1420 protocol and the associated application domain transport network. In 1421 terms of the life time of the keys, the opportunity to periodically 1422 change the encryption key increases the offered level of security for 1423 any given implementation. However, where strong cryptography is 1424 employed, physical, procedural, and logical data access protection 1425 considerations may have more significant impact on cryptoperiod 1426 selection than algorithm and key size factors. Nevertheless, in 1427 general, shorter cryptoperiods, during which a single key is applied, 1428 will enhance security. 1430 Given the mandatory protocol requirement to implement routing node 1431 authentication as part of routing integrity (see Section 9.2), key 1432 exchanges may be coordinated as part of the integrity verification 1433 process. This provides an opportunity to increase the frequency of 1434 key exchange and shorten the cryptoperiod as a complement to the key 1435 length and encryption algorithm required for a given application 1436 domain. For LLNs, the coordination of confidentiality key management 1437 with the implementation of node device authentication can thus reduce 1438 the overhead associated with supporting data confidentiality. If a 1439 new ciphering key is concurrently generated or updated in conjunction 1440 with the mandatory authentication exchange occurring with each 1441 routing peer association, signaling exchange overhead can be reduced. 1443 9.2. Integrity Features 1445 The integrity of routing information provides the basis for ensuring 1446 that the function of the routing protocol is achieved and maintained. 1447 To protect integrity, RPL must either run using only the Secure 1448 versions of the messages, or must run over a layer-2 that uses 1449 channel binding between node identity and transmissions. (i.e.: a 1450 layer-2 which has an identical network-wide transmission key can not 1451 defend against many attacks) 1453 XXX. Logging is critical, but presently impossible. 1455 9.3. Availability Features 1457 Availability of routing information is linked to system and network 1458 availability which in the case of LLNs require a broader security 1459 view beyond the requirements of the routing entities (see 1460 Section 9.5). Where availability of the network is compromised, 1461 routing information availability will be accordingly affected. 1462 However, to specifically assist in protecting routing availability: 1464 o MAY restrict neighborhood cardinality; 1466 o MAY use multiple paths; 1468 o MAY use multiple destinations; 1469 o MAY choose randomly if multiple paths are available; 1471 o MAY set quotas to limit transmit or receive volume; 1473 o MAY use geographic information for flow control. 1475 9.4. Key Management 1477 The functioning of the routing security services requires keys and 1478 credentials. Therefore, even though not directly a ROLL security 1479 requirement, an LLN MUST have a process for initial key and 1480 credential configuration, as well as secure storage within the 1481 associated devices. Anti-tampering SHOULD be a consideration in 1482 physical design. Beyond initial credential configuration, an LLN is 1483 also encouraged to have automatic procedures for the revocation and 1484 replacement of the maintained security credentials. 1486 While RPL has secure modes, but some modes are impractical without 1487 use of public key cryptography believed to be too expensive by many. 1488 RPL layer-3 security will often depend upon existing LLN layer-2 1489 security mechanisms, which provides for node authentication, but 1490 little in the way of node authorization. 1492 9.5. Consideration on Matching Application Domain Needs 1494 Providing security within an LLN requires considerations that extend 1495 beyond routing security to the broader LLN application domain 1496 security implementation. In other words, as routing is one component 1497 of an LLN system, the actual strength of the implemented security 1498 algorithms for the routing protocol MUST be made to conform to the 1499 system's target level of security. The development so far takes into 1500 account collectively the impacts of the issues gathered from 1501 [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. The following two 1502 subsections first consider from an architectural perspective how the 1503 security design of a ROLL protocol may be made to adapt to the four 1504 application domains, and then examine mechanisms and protocol 1505 operations issues. 1507 9.5.1. Security Architecture 1509 The first challenge for a ROLL protocol security design is to have an 1510 architecture that can adequately address a set of very diverse needs. 1511 It is mainly a consequence of the fact that there are both common and 1512 non-overlapping requirements from the four application domains, 1513 while, conceivably, each individual application will present yet its 1514 own unique constraints. 1516 For a ROLL protocol, the security requirements defined in Section 9.1 1517 to Section 9.4 can be addressed at two levels: 1) through measures 1518 implemented directly within the routing protocol itself and initiated 1519 and controlled by the routing protocol entities; or 2) through 1520 measures invoked on behalf of the routing protocol entities but 1521 implemented within the part of the network over which the protocol 1522 exchanges occur. 1524 Where security is directly implemented as part of the routing 1525 protocol the security requirements configured by the user (system 1526 administrator) will operate independently of the lower layers. 1527 OSPFv2 [RFC2328] is an example of such an approach in which security 1528 parameters are exchanged and assessed within the routing protocol 1529 messages. In this case, the mechanism may be, e.g., a header 1530 containing security material of configurable security primitives in 1531 the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is 1532 employed to secure the network, the included protocol-specific (OSPF 1533 or RIP) security elements are in addition to and independent of those 1534 at the network layer. In the case of LLNs or other networks where 1535 system security mandates protective mechanisms at other lower layers 1536 of the network, security measures implemented as part of the routing 1537 protocol will be redundant to security measures implemented elsewhere 1538 as part of the protocol stack. 1540 Security mechanisms built into the routing protocol can ensure that 1541 all desired countermeasures can be directly addressed by the protocol 1542 all the way to the endpoint of the routing exchange. In particular, 1543 routing protocol Byzantine attacks by a compromised node that retains 1544 valid network security credentials can only be detected at the level 1545 of the information exchanged within the routing protocol. Such 1546 attacks aimed at the manipulation of the routing information can only 1547 be fully addressed through measures operating directly between the 1548 routing entities themselves or external entities able to access and 1549 analyze the routing information (see discussion in Section 8.2.5). 1551 On the other hand, it is more desirable from an LLN device 1552 perspective that the ROLL protocol is integrated into the framework 1553 of an overall system architecture where the security facility may be 1554 shared by different applications and/or across layers for efficiency, 1555 and where security policy and configurations can be consistently 1556 specified. See, for example, considerations made in RIPng [RFC2080] 1557 or the approach presented in [Messerges2003]. 1559 Where the routing protocol is able to rely on security measures 1560 configured within other layers of the protocol stack, greater system 1561 efficiency can be realized by avoiding potentially redundant 1562 security. Relying on an open trust model [Messerges2003], the 1563 security requirements of the routing protocol can be more flexibly 1564 met at different layers of the transport network; measures that must 1565 be applied to protect the communications network are concurrently 1566 able to provide the needed routing protocol protection. 1568 For example, where a given security encryption scheme is deemed the 1569 appropriate standard for network confidentiality of data exchanges at 1570 the link layer, that level of security is directly provided to 1571 routing protocol exchanges across the local link. Similarly, where a 1572 given authentication procedure is stipulated as part of the standard 1573 required for authenticating network traffic, that security provision 1574 can then meet the requirement needed for authentication of routing 1575 exchanges. In addition, in the context of the different LLN 1576 application domains, the level of security specified for routing can 1577 and should be consistent with that considered appropriate for 1578 protecting the network within the given environment. 1580 A ROLL protocol MUST be made flexible by a design that offers the 1581 configuration facility so that the user (network administrator) can 1582 choose the security settings that match the application's needs. 1583 Furthermore, in the case of LLNs, that flexibility SHOULD extend to 1584 allowing the routing protocol security requirements to be met by 1585 measures applied at different protocol layers, provided the 1586 identified requirements are collectively met. 1588 Since Byzantine attackers that can affect the validity of the 1589 information content exchanged between routing entities can only be 1590 directly countered at the routing protocol level, the ROLL protocol 1591 MAY support mechanisms for verifying routing data validity that 1592 extend beyond the chain of trust created through device 1593 authentication. This protocol-specific security mechanism SHOULD be 1594 made optional within the protocol allowing it to be invoked according 1595 to the given routing protocol and application domain and as selected 1596 by the system user. All other ROLL security mechanisms needed to 1597 meet the above identified routing security requirements can be 1598 flexibly implemented within the transport network (at the IP network 1599 layer or higher or lower protocol layers(s)) according to the 1600 particular application domain and user network configuration. 1602 Based on device capabilities and the spectrum of operating 1603 environments it would be difficult for a single fixed security design 1604 to be applied to address the diversified needs of the urban, 1605 industrial, home, and building ROLL application domains, and 1606 foreseeable others, without forcing a very low common denominator set 1607 of requirements. On the other hand, providing four individual domain 1608 designs that attempt to a priori match each individual domain is also 1609 very unlikely to provide a suitable answer given the degree of 1610 network variability even within a given domain; furthermore, the type 1611 of link layers in use within each domain also influences the overall 1612 security. 1614 Instead, the framework implementation approach recommended is for 1615 optional, routing protocol-specific measures that can be applied 1616 separately from, or together with, flexible transport network 1617 mechanisms. Protocol-specific measures include the specification of 1618 valid parameter ranges, increments and/or event frequencies that can 1619 be verified by individual routing devices. In addition to deliberate 1620 attacks this allows basic protocol sanity checks against 1621 unintentional mis-configuration. Transport network mechanisms would 1622 include out-of-band communications that may be defined to allow an 1623 external entity to request and process individual device information 1624 as a means to effecting an external verification of the derived 1625 network routing information to identify the existence of intentional 1626 or unintentional network anomalies. 1628 This approach allows countermeasures against byzantine attackers to 1629 be applied in environments where applicable threats exist. At the 1630 same time, it allows routing protocol security to be supported 1631 through measures implemented within the transport network that are 1632 consistent with available system resources and commensurate and 1633 consistent with the security level and strength applied in the 1634 particular application domain networks. 1636 9.5.2. Mechanisms and Operations 1637 With an architecture allowing different configurations to meet the 1638 application domain needs, the task is then to find suitable 1639 mechanisms. For example, one of the main problems of synchronizing 1640 security states of sleepy nodes lies in difficulties in 1641 authentication; these nodes may not have received in time the most 1642 recent update of security material. Similarly, the issues of minimal 1643 manual configuration, prolonged rollout and delayed addition of 1644 nodes, and network topology changes also complicate security 1645 management. In many cases the ROLL protocol may need to bootstrap 1646 the authentication process and allow for a flexible expiration scheme 1647 of authentication credentials. This exemplifies the need for the 1648 coordination and interoperation between the requirements of the ROLL 1649 routing protocol and that of the system security elements. 1651 Similarly, the vulnerability brought forth by some special-function 1652 nodes, e.g., LBRs requires the assurance, particularly, of the 1653 availability of communication channels and node resources, or that 1654 the neighbor discovery process operates without undermining routing 1655 availability. 1657 There are other factors which are not part of a ROLL routing protocol 1658 but which can still affect its operation. These include elements 1659 such as weaker barrier to accessing the data or security material 1660 stored on the nodes through physical means; therefore, the internal 1661 and external interfaces of a node need to be adequate for guarding 1662 the integrity, and possibly the confidentiality, of stored 1663 information, as well as the integrity of routing and route generation 1664 processes. 1666 Figure 5 provides an overview of the larger context of system 1667 security and the relationship between ROLL requirements and measures 1668 and those that relate to the LLN system. 1670 Security Services for 1671 ROLL-Addressable 1672 Security Requirements 1673 | | 1674 +---+ +---+ 1675 Node_i | | Node_j 1676 _____v___ ___v_____ 1677 Specify Security / \ / \ Specify Security 1678 Requirements | Routing | | Routing | Requirements 1679 +---------| Protocol| | Protocol|---------+ 1680 | | Entity | | Entity | | 1681 | \_________/ \_________/ | 1682 | | | | 1683 |ROLL-Specified | | ROLL-Specified| 1685 ---Interface | | Interface--- 1686 | ...................................... | 1687 | : | | : | 1688 | : +-----+----+ +----+-----+ : | 1689 | : |Transport/| |Transport/| : | 1690 ____v___ : +>|Network | |Network |<+ : ___v____ 1691 / \ : | +-----+----+ +----+-----+ | : / \ 1692 | |-:-+ | | +-:-| | 1693 |Security| : +-----+----+ +----+-----+ : |Security| 1694 +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ 1695 | |Entity | : +-----+----+ +----+-----+ : |Entity | | 1696 | | |-:-+ | | +-:-| | | 1697 | \________/ : | +-----+----+ +----+-----+ | : \________/ | 1698 | : +>| Physical | | Physical |<+ : | 1699 Application : +-----+----+ +----+-----+ : Application 1700 Domain User : | | : Domain User 1701 Configuration : |__Comm. Channel_| : Configuration 1702 : : 1703 ...Protocol Stack..................... 1705 Figure 5: LLN Device Security Model 1707 10. IANA Considerations 1709 This memo includes no request to IANA. 1711 11. Security Considerations 1713 The analysis presented in this document provides security analysis 1714 and design guidelines with a scope limited to ROLL. Security 1715 services are identified as requirements for securing ROLL. The 1716 specific mechanisms to be used to deal with each threat is specified 1717 in link-layer and deployment specific applicability statements. 1719 12. Acknowledgments 1721 The authors would like to acknowledge the review and comments from 1722 Rene Struik and JP Vasseur. The authors would also like to 1723 acknowledge the guidance and input provided by the ROLL Chairs, David 1724 Culler, and JP Vasseur, and the Area Director Adrian Farrel. 1726 This document started out as a combined threat and solutions 1727 document. As a result of security review, the document was split up 1728 by ROLL co-Chair Michael Richardson and security Area Director Sean 1729 Turner as it went through the IETF publication process. The 1730 solutions to the threads are application and layer-2 specific, and 1731 have therefore been moved to the relevant applicability statements. 1733 Ines Robles kept track of the many issues that were raised during the 1734 development of this document 1736 13. References 1738 13.1. Normative References 1740 [I-D.ietf-roll-terminology] 1741 Vasseur, J., "Terminology in Low power And Lossy 1742 Networks", draft-ietf-roll-terminology-04 (work in 1743 progress), September 2010. 1745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1746 Requirement Levels", BCP 14, RFC 2119, March 1997. 1748 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1749 Key Management", BCP 107, RFC 4107, June 2005. 1751 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1752 Internet Protocol", RFC 4301, December 2005. 1754 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1755 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1756 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1757 Lossy Networks", RFC 6550, March 2012. 1759 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 1760 Hysteresis Objective Function", RFC 6719, September 2012. 1762 13.2. Informative References 1764 [FIPS197] , "Federal Information Processing Standards Publication 1765 197: Advanced Encryption Standard (AES)", US National 1766 Institute of Standards and Technology, Nov. 26 2001. 1768 [Huang2003] 1769 Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. 1770 Zhang, "Fast Authenticated Key Establishment Protocols for 1771 Self-Organizing Sensor Networks", in Proceedings of the 1772 2nd ACM International Conference on Wireless Sensor 1773 Networks and Applications, San Diego, CA, USA, pp. 1774 141-150, Sept. 19 2003. 1776 [I-D.alexander-roll-mikey-lln-key-mgmt] 1777 Alexander, R. and T. Tsao, "Adapted Multimedia Internet 1778 KEYing (AMIKEY): An extension of Multimedia Internet 1779 KEYing (MIKEY) Methods for Generic LLN Environments", 1780 draft-alexander-roll-mikey-lln-key-mgmt-04 (work in 1781 progress), September 2012. 1783 [I-D.kelsey-intarea-mesh-link-establishment] 1784 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 1785 intarea-mesh-link-establishment-05 (work in progress), 1786 February 2013. 1788 [I-D.suhopark-hello-wsn] 1789 Park, S., "Routing Security in Sensor Network: HELLO Flood 1790 Attack and Defense", draft-suhopark-hello-wsn-00 (work in 1791 progress), December 2005. 1793 [IEEE1149.1] 1794 , "IEEE Standard Test Access Port and Boundary Scan 1795 Architecture", IEEE-SA Standards Board, Jun. 14 2001. 1797 [ISO.7498-2.1988] 1798 International Organization for Standardization, 1799 "Information Processing Systems - Open Systems 1800 Interconnection Reference Model - Security Architecture", 1801 ISO Standard 7498-2, 1988. 1803 [Karlof2003] 1804 Karlof, C. and D. Wagner, "Secure routing in wireless 1805 sensor networks: attacks and countermeasures", Elsevier 1806 AdHoc Networks Journal, Special Issue on Sensor Network 1807 Applications and Protocols, 1(2):293-315, September 2003. 1809 [Kasumi3gpp] 1810 , "3GPP TS 35.202 Specification of the 3GPP 1811 confidentiality and integrity algorithms; Document 2: 1812 Kasumi specification", 3GPP TSG SA3, 2009. 1814 [Messerges2003] 1815 Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, 1816 R., and E. Callaway, "Low-Power Security for Wireless 1817 Sensor Networks", in Proceedings of the 1st ACM Workshop 1818 on Security of Ad Hoc and Sensor Networks, Fairfax, VA, 1819 USA, pp. 1-11, Oct. 31 2003. 1821 [Myagmar2005] 1822 Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as 1823 a Basis for Security Requirements", in Proceedings of the 1824 Symposium on Requirements Engineering for Information 1825 Security (SREIS'05), Paris, France, pp. 94-102, Aug 29, 1826 2005. 1828 [Perlman1988] 1829 Perlman, N., "Network Layer Protocols with Byzantine 1830 Robustness", MIT LCS Tech Report, 429, 1988. 1832 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC 1833 1142, February 1990. 1835 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1836 January 1997. 1838 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1840 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1841 1998. 1843 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1844 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1845 August 2004. 1847 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1848 "Multicast Security (MSEC) Group Key Management 1849 Architecture", RFC 4046, April 2005. 1851 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1852 Routing Protocols", RFC 4593, October 2006. 1854 [RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of- 1855 Service Considerations", RFC 4732, December 2006. 1857 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 1858 4949, August 2007. 1860 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 1861 Polk, "Server-Based Certificate Validation Protocol 1862 (SCVP)", RFC 5055, December 2007. 1864 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 1865 Various Multimedia Internet KEYing (MIKEY) Modes and 1866 Extensions", RFC 5197, June 2008. 1868 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1869 "Routing Requirements for Urban Low-Power and Lossy 1870 Networks", RFC 5548, May 2009. 1872 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1873 "Industrial Routing Requirements in Low-Power and Lossy 1874 Networks", RFC 5673, October 2009. 1876 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1877 Mail Extensions (S/MIME) Version 3.2 Message 1878 Specification", RFC 5751, January 2010. 1880 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1881 Routing Requirements in Low-Power and Lossy Networks", RFC 1882 5826, April 2010. 1884 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1885 "Building Automation Routing Requirements in Low-Power and 1886 Lossy Networks", RFC 5867, June 2010. 1888 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1889 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 1890 5996, September 2010. 1892 [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the 1893 Router Control Plane", RFC 6192, March 2011. 1895 [Szcze2008] 1896 Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M., 1897 and R. Dahab, "NanoECC: testing the limits of elliptic 1898 curve cryptography in sensor networks", pp. 324-328, 2008, 1899 . 1902 [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A 1903 Secure Distance Vector Routing Protocol", in Proceedings 1904 of the 2nd International Conference on Applied 1905 Cryptography and Network Security, Yellow Mountain, China, 1906 pp. 103-119, Jun. 8-11 2004. 1908 [Wander2005] 1909 Wander, A., Gura, N., Eberle, H., Gupta, V., and S. 1910 Shantz, "Energy analysis of public-key cryptography for 1911 wireless sensor networ", in the Proceedings of the Third 1912 IEEE International Conference on Pervasive Computing and 1913 Communications pp. 324-328, March 8-12 2005. 1915 [Yourdon1979] 1916 Yourdon, E. and L. Constantine, "Structured Design", 1917 Yourdon Press, New York, Chapter 10, pp. 187-222, 1979. 1919 Authors' Addresses 1921 Tzeta Tsao 1922 Cooper Power Systems 1923 910 Clopper Rd. Suite 201S 1924 Gaithersburg, Maryland 20878 1925 USA 1927 Email: tzeta.tsao@cooperindustries.com 1929 Roger K. Alexander 1930 Cooper Power Systems 1931 910 Clopper Rd. Suite 201S 1932 Gaithersburg, Maryland 20878 1933 USA 1935 Email: roger.alexander@cooperindustries.com 1937 Mischa Dohler 1938 CTTC 1939 Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 1940 Castelldefels, Barcelona 08860 1941 Spain 1943 Email: mischa.dohler@cttc.es 1945 Vanesa Daza 1946 Universitat Pompeu Fabra 1947 P/ Circumval.lacio 8, Oficina 308 1948 Barcelona 08003 1949 Spain 1951 Email: vanesa.daza@upf.edu 1952 Angel Lozano 1953 Universitat Pompeu Fabra 1954 P/ Circumval.lacio 8, Oficina 309 1955 Barcelona 08003 1956 Spain 1958 Email: angel.lozano@upf.edu 1960 Michael Richardson (ed) 1961 Sandelman Software Works 1962 470 Dawson Avenue 1963 Ottawa, ON K1Z5V7 1964 Canada 1966 Email: mcr+ietf@sandelman.ca