idnits 2.17.1 draft-ietf-roll-security-threats-03.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 (June 25, 2013) is 3957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IS07498-2' is mentioned on line 155, but not defined -- 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 (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group T. Tsao 3 Internet-Draft R. Alexander 4 Intended status: Informational Cooper Power Systems 5 Expires: December 27, 2013 M. Dohler 6 CTTC 7 V. Daza 8 A. Lozano 9 Universitat Pompeu Fabra 10 June 25, 2013 12 A Security Threat Analysis for Routing over Low-Power and Lossy Networks 13 draft-ietf-roll-security-threats-03 15 Abstract 17 This document presents a security threat analysis for routing over 18 low-power and lossy networks (LLN). The development builds upon 19 previous work on routing security and adapts the assessments to the 20 issues and constraints specific to low-power and lossy networks. A 21 systematic approach is used in defining and evaluating the security 22 threats. Applicable countermeasures are application specific and are 23 addressed in relevant applicability statements. These assessments 24 provide the basis of the security recommendations for incorporation 25 into low-power, lossy network routing protocols. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in RFC 32 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 27, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 6 70 3.1. Routing Assets and Points of Access . . . . . . . . . . . 7 71 3.2. The ISO 7498-2 Security Reference Model . . . . . . . . . 9 72 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 11 73 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 12 74 4. Threat Sources . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 14 76 5.1. Threats due to failures to Authenticate . . . . . . . . . 14 77 5.2. Threats due to failures to Authenticate . . . . . . . . . 14 78 5.3. Threats and Attacks on Confidentiality . . . . . . . . . . 14 79 5.3.1. Routing Exchange Exposure . . . . . . . . . . . . . . 15 80 5.3.2. Routing Information (Routes and Network Topology) 81 Exposure . . . . . . . . . . . . . . . . . . . . . . . 15 82 6. Threats and Attacks on Integrity . . . . . . . . . . . . . . . 16 83 6.1. Routing Information Manipulation . . . . . . . . . . . . . 16 84 6.2. Node Identity Misappropriation . . . . . . . . . . . . . . 17 85 7. Threats and Attacks on Availability . . . . . . . . . . . . . 17 86 7.1. Routing Exchange Interference or Disruption . . . . . . . 17 87 7.2. Network Traffic Forwarding Disruption . . . . . . . . . . 18 88 7.3. Communications Resource Disruption . . . . . . . . . . . . 19 89 7.4. Node Resource Exhaustion . . . . . . . . . . . . . . . . . 20 90 8. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 20 91 8.1. Confidentiality Attack Countermeasures . . . . . . . . . . 21 92 8.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 21 93 8.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 21 94 8.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 22 95 8.1.4. Countering Physical Device Compromise . . . . . . . . 23 96 8.1.5. Countering Remote Device Access Attacks . . . . . . . 25 97 8.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 26 98 8.2.1. Countering Unauthorized Modification Attacks . . . . . 26 99 8.2.2. Countering Overclaiming and Misclaiming Attacks . . . 26 100 8.2.3. Countering Identity (including Sybil) Attacks . . . . 27 101 8.2.4. Countering Routing Information Replay Attacks . . . . 27 102 8.2.5. Countering Byzantine Routing Information Attacks . . . 27 103 8.3. Availability Attack Countermeasures . . . . . . . . . . . 28 104 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing 105 Attacks . . . . . . . . . . . . . . . . . . . . . . . 29 106 8.3.2. Countering Overload Attacks . . . . . . . . . . . . . 30 107 8.3.3. Countering Selective Forwarding Attacks . . . . . . . 31 108 8.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 32 109 8.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 33 110 9. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 33 111 9.1. Confidentiality Features . . . . . . . . . . . . . . . . . 34 112 9.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 35 113 9.3. Availability Features . . . . . . . . . . . . . . . . . . 36 114 9.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 37 115 9.5. Consideration on Matching Application Domain Needs . . . . 38 116 9.5.1. Security Architecture . . . . . . . . . . . . . . . . 38 117 9.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 41 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 120 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 122 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 123 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 126 1. Introduction 128 In recent times, networked electronic devices have found an 129 increasing number of applications in various fields. Yet, for 130 reasons ranging from operational application to economics, these 131 wired and wireless devices are often supplied with minimum physical 132 resources; the constraints include those on computational resources 133 (RAM, clock speed, storage), communication resources (duty cycle, 134 packet size, etc.), but also form factors that may rule out user 135 access interfaces (e.g., the housing of a small stick-on switch), or 136 simply safety considerations (e.g., with gas meters). As a 137 consequence, the resulting networks are more prone to loss of traffic 138 and other vulnerabilities. The proliferation of these low-power and 139 lossy networks (LLNs), however, are drawing efforts to examine and 140 address their potential networking challenges. Securing the 141 establishment and maintenance of network connectivity among these 142 deployed devices becomes one of these key challenges. 144 This document presents a threat analysis for securing Routing Over 145 LLNs (ROLL) through an analysis that starts from the routing basics. 146 The objective is two-fold. First, the analysis will be used to 147 identify pertinent security issues. Second, it will facilitate both 148 the assessment of a protocol's security threats and the 149 identification of necessary countermeasures to secure the ROLL 150 protocols. The approach adopted is a five step process, 1) examine 151 security issues in ROLL, 2) describe the threat sources, 3) analyze 152 threats and attacks, 4) consider countermeasures, and 5) provide 153 recommendations for securing ROLL. 155 This document uses [IS07498-2] model, which includes Authentication, 156 Access Control, Data Confidentiality, Data Integrity, and Non- 157 Repudiation but to which Availability is added. 159 spt: If this is just about control plane security then we should say 160 so right up front. 162 2. Terminology 164 This document adopts the terminology defined in [RFC6550] and in 165 [RFC4949], with the following addition: 167 Control Sequence Control plane: Supports routing and management 168 functions. 170 Data Plane Data plane: See Forwarding plane. 172 Data Plane Forwarding plane: Responsible for receiving a packet on 173 an incoming interface, performing a lookup to identify the 174 packet's next hop and determine the best outgoing interface 175 towards the destination, and forwarding the packet out through 176 the appropriate outgoing interface. 178 Node An element of a low-power, lossy network that may be a router 179 or a host. 181 Sleepy Node A sleepy node is a Node that may sometimes go into a 182 sleep mode (i.e. go into a low power state to conserve power) 183 and temporarily suspends communication but that is immediately 184 available. 186 3. Considerations on ROLL Security 188 Routing security, in essence, ensures that the routing protocol 189 operates correctly. It entails implementing measures to ensure 190 controlled state changes on devices and network elements, both based 191 on external inputs (received via communications) or internal inputs 192 (physical security of device itself and parameters maintained by the 193 device, including, e.g., clock). State changes would thereby involve 194 not only authorization of injector's actions, authentication of 195 injectors, authentication, integrity, and potentially confidentiality 196 of routing data, but also proper order of state changes through 197 timeliness, since seriously delayed state changes, such as commands 198 or updates of routing tables, may negatively impact system operation. 199 A security assesment can therefore begin with a focus on the 200 assetsRFC4949 [RFC4949]that may be the target of the state changes 201 and the access points in terms of interfaces and protocol exchanges 202 through which such changes may occur. In the case of routing 203 security the focus is directed towards the elements associated with 204 the establishment and maintenance of network connectivity. 206 This section sets the stage for the development of the analysis by 207 applying the systematic approach proposed in [Myagmar2005] to the 208 routing security, while also drawing references from other reviews 209 and assessments found in the literature, particularly, [RFC4593] and 210 [Karlof2003]. The subsequent subsections begin with a focus on the 211 elements of a generic routing process that is used to establish 212 routing assets and points of access to the routing functionality. 213 Next, the ISO 7498-2 security model is briefly described. Then, 214 consideration is given to issues specific to or amplified in LLNs. 215 This section concludes with the formulation of a set of security 216 objectives for ROLL. 218 3.1. Routing Assets and Points of Access 220 An asset is an important system resource (including information, 221 process, or physical resource), the access to, corruption or loss of 222 which adversely affects the system. In the control plane context, an 223 asset is information about the network, processes used to manage and 224 manipulate this data, and the physical devices on which this data is 225 stored and manipulated. The corruption or loss of these assets may 226 adversely impact the control plane of the network. Within the same 227 context, a point of access is an interface or protocol that 228 facilitates interaction between control plane components. 229 Identifying these assets and points of access will provide a basis 230 for enumerating the attack surface of the control plane. 232 A level-0 data flow diagram [Yourdon1979] is used here to identify 233 the assets and points of access within a generic routing process. 234 The use of a data flow diagram allows for a clear and concise model 235 of the way in which routing nodes interact and process information, 236 and hence provides a context for threats and attacks. The goal of 237 the model is to be as detailed as possible so that corresponding 238 assets, points of access, and process in an individual routing 239 protocol can be readily identified. 241 Figure 1 shows that nodes participating in the routing process 242 transmit messages to discover neighbors and to exchange routing 243 information; routes are then generated and stored, which may be 244 maintained in the form of the protocol forwarding table. The nodes 245 use the derived routes for making forwarding decisions. 247 ................................................... 248 : : 249 : : 250 |Node_i|<------->(Routing Neighbor _________________ : 251 : Discovery)------------>Neighbor Topology : 252 : -------+--------- : 253 : | : 254 |Node_j|<------->(Route/Topology +--------+ : 255 : Exchange) | : 256 : | V ______ : 257 : +---->(Route Generation)--->Routes : 258 : ---+-- : 259 : | : 260 : Routing on a Node Node_k | : 261 ................................................... 262 | 263 |Forwarding | 264 |On Node_l|<-------------------------------------------+ 266 Notation: 268 (Proc) A process Proc 270 ________ 271 DataBase A data storage DataBase 272 -------- 274 |Node_n| An external entity Node_n 276 -------> Data flow 278 Figure 1: Data Flow Diagram of a Generic Routing Process 280 It is seen from Figure 1 that 282 o Assets include 284 * routing and/or topology information; 286 * route generation process; 288 * communication channel resources (bandwidth); 290 * node resources (computing capacity, memory, and remaining 291 energy); 293 * node identifiers (including node identity and ascribed 294 attributes such as relative or absolute node location). 296 o Points of access include 298 * neighbor discovery; 300 * route/topology exchange; 302 * node physical interfaces (including access to data storage). 304 A focus on the above list of assets and points of access enables a 305 more directed assessment of routing security; for example, it is 306 readily understood that some routing attacks are in the form of 307 attempts to misrepresent routing topology. Indeed, the intention of 308 the security threat analysis is to be comprehensive. Hence, some of 309 the discussion which follows is associated with assets and points of 310 access that are not directly related to routing protocol design but 311 nonetheless provided for reference since they do have direct 312 consequences on the security of routing. 314 3.2. The ISO 7498-2 Security Reference Model 316 At the conceptual level, security within an information system in 317 general and applied to ROLL in particular is concerned with the 318 primary issues of authentication, access control, data 319 confidentiality, data integrity, and non-repudiation. In the context 320 of ROLL 322 Authentication 323 Authentication involves the mutual authentication of the 324 routing peers prior to exchanging route information (i.e., peer 325 authentication) as well as ensuring that the source of the 326 route data is from the peer (i.e., data origin authentication). 327 From 5478 LLNs can be drained by unauthenticated peers before 328 confirguratin From 5673 This requires availability of open and 329 untrusted side channels for new joiners, and it requires strong 330 and automated authentication so that networks can automatically 331 accept or reject new joiners. spt: Do we need more here? 333 Access Control 334 Access Control provides protection against unauthorized use of 335 the asset, and deals with the authorization of a node. 337 Confidentiality 338 Confidentiality involves the protection of routing information 339 as well as routing neighbor maintenance exchanges so that only 340 authorized and intended network entities may view or access it. 342 Because LLNs are most commonly found on a publicly accessible 343 shared medium, e.g., air or wiring in a building, and sometimes 344 formed ad hoc, confidentiality also extends to the neighbor 345 state and database information within the routing device since 346 the deployment of the network creates the potential for 347 unauthorized access to the physical devices themselves. 349 Integrity 350 Integrity entails the protection of routing information and 351 routing neighbor maintenance exchanges, as well as derived 352 information maintained in the database, from unauthorized 353 modification, insertions, deletions or replays. to be addressed 354 beyond the routing protocol. 356 Non-repudiation 357 Non-repudiation is the assurance that the transmission and/or 358 reception of a message cannot later be denied. The service of 359 non-repudiation applies after-the-fact and thus relies on the 360 logging or other capture of on-going message exchanges and 361 signatures. Applied to routing, non-repudiation is not an 362 issue because it does not apply to routing protocols, which are 363 machine-to-machine protocols. Further, with the LLN 364 application domains as described in RFC5548 [RFC5867], 365 proactive measures are much more critical than retrospective 366 protections. Finally, given the significant practical limits 367 to on-going routing transaction logging and storage and 368 individual device digital signature verification for each 369 exchange, non-repudiation in the context of routing is an 370 unsupportable burden that bears no further considered as a ROLL 371 security issue. 373 It is recognized that, besides those security issues captured in the 374 ISO 7498-2 model, availability, is a security requirement: 376 Availability 377 Availability ensures that routing information exchanges and 378 forwarding services need to be available when they are required 379 for the functioning of the serving network. Availability will 380 apply to maintaining efficient and correct operation of routing 381 and neighbor discovery exchanges (including needed information) 382 and forwarding services so as not to impair or limit the 383 network's central traffic flow function 385 It should be emphasized here that for ROLL security the above 386 requirements must be complemented by the proper security policies and 387 enforcement mechanisms to ensure that security objectives are met by 388 a given ROLL implementation. 390 3.3. Issues Specific to or Amplified in LLNs 392 The work [RFC5548], [RFC5673], [RFC5826], and [RFC5867] have 393 identified specific issues and constraints of routing in LLNs for the 394 urban, industrial, home automation, and building automation 395 application domains, respectively. The following is a list of 396 observations and evaluation of their impact on routing security 397 considerations. 399 Limited energy, memory, and processing node resources 400 As a consequence of these constraints, there is an even more 401 critical need than usual for a careful study of trade-offs on 402 which and what level of security services are to be afforded 403 during the system design process. The chosen security 404 mechanisms also needs to work within these constraints. 405 Synchronization of security states with sleepy nodes is yet 406 another issue. 408 Large scale of rolled out network 409 The possibly numerous nodes to be deployed, e.g., an urban 410 deployment can see several hundreds of thousands of nodes, as 411 well as the generally low level of expertise expected of the 412 installers, make manual on-site configuration unlikely. 413 Prolonged rollout and delayed addition of nodes, which may be 414 from old inventory, over the lifetime of the network, also 415 complicate the operations of key management. 417 Autonomous operations 418 Self-forming and self-organizing are commonly prescribed 419 requirements of LLNs. In other words, a routing protocol 420 designed for LLNs needs to contain elements of ad hoc 421 networking and in most cases cannot rely on manual 422 configuration for initialization or local filtering rules. 423 Network topology/ownership changes, partitioning or merging, as 424 well as node replacement, can all contribute to complicating 425 the operations of key management. 427 Highly directional traffic 428 Some types of LLNs see a high percentage of their total traffic 429 traverse between the nodes and the LLN Border Routers (LBRs) 430 where the LLNs connect to non-LLNs. The special routing status 431 of and the greater volume of traffic near the LBRs have routing 432 security consequences as a higher valued attack target. In 433 fact, when Point-to-MultiPoint (P2MP) and MultiPoint-to-Point 434 (MP2P) traffic represents a majority of the traffic, routing 435 attacks consisting of advertising incorrect preferred routes 436 can cause serious damage. 438 Unattended locations and limited physical security 439 Many applications have the nodes deployed in unattended or 440 remote locations; furthermore, the nodes themselves are often 441 built with minimal physical protection. These constraints 442 lower the barrier of accessing the data or security material 443 stored on the nodes through physical means. 445 Support for mobility 446 On the one hand, only a number of applications require the 447 support of mobile nodes, e.g., a home LLN that includes nodes 448 on wearable health care devices or an industry LLN that 449 includes nodes on cranes and vehicles. On the other hand, if a 450 routing protocol is indeed used in such applications, it will 451 clearly need to have corresponding security mechanisms. 453 Support for multicast and anycast 454 Support for multicast and anycast is called out chiefly for 455 large-scale networks. Since application of these routing 456 mechanisms in autonomous operations of many nodes is new, the 457 consequence on security requires careful consideration. 459 The above list considers how an LLN's physical constraints, size, 460 operations, and variety of application areas may impact security. 461 However, it is the combinations of these factors that particularly 462 stress the security concerns. For instance, securing routing for a 463 large number of autonomous devices that are left in unattended 464 locations with limited physical security presents challenges that are 465 not found in the common circumstance of administered networked 466 routers. The following subsection sets up the security objectives 467 for the routing protocol designed by the ROLL WG. 469 3.4. ROLL Security Objectives 471 This subsection applies the ISO 7498-2 model to routing assets and 472 access points, taking into account the LLN issues, to develop a set 473 of ROLL security objectives. 475 Since the fundamental function of a routing protocol is to build 476 routes for forwarding packets, it is essential to ensure that: 478 o routing/topology information iintegrity remains intact during 479 transfer and in storage; 481 o routing/topology information is used by authorized entities; 483 o routing/topology information is available when needed. 485 In conjunction, it is necessary to be assured that 486 o authorized peers authenticate themselves during the routing 487 neighbor discovery process; 489 o the routing/topology information received is generated according 490 to the protocol design. 492 However, when trust cannot be fully vested through authentication of 493 the principals alone, i.e., concerns of insider attack, assurance of 494 the truthfulness and timeliness of the received routing/topology 495 information is necessary. With regard to confidentiality, protecting 496 the routing/topology information from unauthorized exposure may be 497 desirable in certain cases but is in itself less pertinent in general 498 to the routing function. 500 One of the main problems of synchronizing security states of sleepy 501 nodes, as listed in the last subsection, lies in difficulties in 502 authentication; these nodes may not have received in time the most 503 recent update of security material. Similarly, the issues of minimal 504 manual configuration, prolonged rollout and delayed addition of 505 nodes, and network topology changes also complicate key management. 506 Hence, routing in LLNs needs to bootstrap the authentication process 507 and allow for flexible expiration scheme of authentication 508 credentials. 510 The vulnerability brought forth by some special-function nodes, e.g., 511 LBRs, requires the assurance, particularly in a security context, 513 o of the availability of communication channels and node resources; 515 o that the neighbor discovery process operates without undermining 516 routing availability. 518 There are other factors which are not part of a ROLL protocol but 519 directly affecting its function. These factors include weaker 520 barrier of accessing the data or security material stored on the 521 nodes through physical means; therefore, the internal and external 522 interfaces of a node need to be adequate for guarding the integrity, 523 and possibly the confidentiality, of stored information, as well as 524 the integrity of routing and route generation processes. 526 Each individual system's use and environment will dictate how the 527 above objectives are applied, including the choices of security 528 services as well as the strengths of the mechanisms that must be 529 implemented. The next two sections take a closer look at how the 530 ROLL security objectives may be compromised and how those potential 531 compromises can be countered. 533 4. Threat Sources 535 provides a detailed review of the threat sources: outsiders and 536 byzantine. ROLL has the same threat sources. [RFC4593] 538 5. Threats and Attacks 540 This section outlines general categories of threats under the ISO 541 7498-2 model and highlights the specific attacks in each of these 542 categories for ROLL. As defined in [RFC4949], a threat is "a 543 potential for violation of security, which exists when there is a 544 circumstance, capability, action, or event that could breach security 545 and cause harm." 547 An attack is "an assault on system security that derives from an 548 intelligent threat, i.e., an intelligent act that is a deliberate 549 attempt (especially in the sense of a method or technique) to evade 550 security services and violate the security policy of a system." 552 The subsequent subsections consider the threats and the attacks that 553 can cause security breaches under the ISO 7498-2 model to the routing 554 assets and via the routing points of access identified in 555 Section 3.1. The assessment steps through the security concerns of 556 each routing asset and looks at the attacks that can exploit routing 557 points of access. The threats and attacks identified are based on 558 the routing model analysis and associated review of the existing 559 literature. The source of the attacks is assumed to be from either 560 inside or outside attackers Section 4, whose capabilities may be 561 limited to node-equivalent or more sophisticated computing platforms. 563 5.1. Threats due to failures to Authenticate 565 5.2. Threats due to failures to Authenticate 567 5.3. Threats and Attacks on Confidentiality 569 The assessment in Section 3.2 indicates that there are threat actions 570 against the confidentiality of routing information at all points of 571 access. The confidentiality threat consequences is disclosure, see 572 Section 3.1.2 of [RFC4593]. For ROLL this is the disclosure of 573 routing information either by evesdropping on the communication 574 exchanges between routing nodes or by direct access of node's 575 information. 577 5.3.1. Routing Exchange Exposure 579 Routing exchanges include both routing information as well as 580 information associated with the establishment and maintenance of 581 neighbor state information. As indicated in Section 3.1, the 582 associated routing information assets may also include device 583 specific resource information, such as memory, remaining power, etc., 584 that may be metrics of the routing protocol. 586 The routing exchanges will contain reachability information, which 587 would identify the relative importance of different nodes in the 588 network. Nodes higher up in the DODAG, to which more streams of 589 information flow, would be more interesting targets for other 590 attacks, and routing exchange exposures can identify them. 592 5.3.2. Routing Information (Routes and Network Topology) Exposure 594 Routes (which may be maintained in the form of the protocol 595 forwarding table) and neighbor topology information are the products 596 of the routing process that are stored within the node device 597 databases. 599 The exposure of this information will allow attachers to gain direct 600 access to the configuration and connectivity of the network thereby 601 exposing routing to targeted attacks on key nodes or links. Since 602 routes and neighbor topology information is stored within the node 603 device, threats or attacks on the confidentiality of the information 604 will apply to the physical device including specified and unspecified 605 internal and external interfaces. 607 The forms of attack that allow unauthorized access or disclosure of 608 the routing information (other than occurring through explicit node 609 exchanges) will include: 611 o Physical device compromise; 613 o Remote device access attacks (including those occurring through 614 remote network management or software/field upgrade interfaces). 616 Both of these attack vectors are considered a device specific issue, 617 and are out of scope for the RPL protocol to defend against. In some 618 applications, physical device compromise may be a real threat and it 619 may be necessary to provide for other devices to react quickly to 620 exclude a compromised device. 622 6. Threats and Attacks on Integrity 624 The assessment in Section 3.2 indicates that information and identity 625 assets are exposed to integrity threats from all points of access. 626 In other words, the integrity threat space is defined by the 627 potential for exploitation introduced by access to assets available 628 through routing exchanges and the on-device storage. 630 6.1. Routing Information Manipulation 632 Manipulation of routing information that range from neighbor states 633 to derived routes will allow unauthorized sources to influence the 634 operation and convergence of the routing protocols and ultimately 635 impact the forwarding decisions made in the network. 637 Manipulation of topology and reachability information will allow 638 unauthorized sources to influence the nodes with which routing 639 information is exchanged and updated. The consequence of 640 manipulating routing exchanges can thus lead to sub-optimality and 641 fragmentation or partitioning of the network by restricting the 642 universe of routers with which associations can be established and 643 maintained. 645 A sub-optimal network may use too much power and/or may congest some 646 routes leading to premature failure of a node, and a denial of 647 service on the entire network. 649 In addition, being able to attract network traffic can make a 650 blackhole attack more damaging. 652 The forms of attack that allow manipulation to compromise the content 653 and validity of routing information include 655 o Falsification, including overclaiming and misclaiming; 657 o Routing information replay; 659 o Byzantine (internal) attacks that permit corruption of routing 660 information in the node even where the node continues to be a 661 validated entity within the network (see, for example, [RFC4593] 662 for further discussions on Byzantine attacks); 664 o Physical device compromise or remote device access attacks. 666 6.2. Node Identity Misappropriation 668 Falsification or misappropriation of node identity between routing 669 participants opens the door for other attacks; it can also cause 670 incorrect routing relationships to form and/or topologies to emerge. 671 Routing attacks may also be mounted through less sophisticated node 672 identity misappropriation in which the valid information broadcast or 673 exchanged by a node is replayed without modification. The receipt of 674 seemingly valid information that is however no longer current can 675 result in routing disruption, and instability (including failure to 676 converge). Without measures to authenticate the routing participants 677 and to ensure the freshness and validity of the received information 678 the protocol operation can be compromised. The forms of attack that 679 misuse node identity include 681 o Identity attacks, including Sybil attacks in which a malicious 682 node illegitimately assumes multiple identities; 684 o Routing information replay. 686 7. Threats and Attacks on Availability 688 The assessment in Section 3.2 indicates that the process and 689 resources assets are exposed to threats against availability; attacks 690 in this category may exploit directly or indirectly information 691 exchange or forwarding (see [RFC4732] for a general discussion). 693 7.1. Routing Exchange Interference or Disruption 695 Interference is the threat action and disruption is threat 696 consequence that allows attackers to influence the operation and 697 convergence of the routing protocols by impeding the routing 698 information exchange. 700 The forms of attack that allow interference or disruption of routing 701 exchange include: 703 o Routing information replay; 705 o ACK spoofing; 707 o Overload attacks. 709 In addition, attacks may also be directly conducted at the physical 710 layer in the form of jamming or interfering. 712 7.2. Network Traffic Forwarding Disruption 714 The disruption of the network traffic forwarding capability will 715 undermine the central function of network routers and the ability to 716 handle user traffic. This affects the availability of the network 717 because of the potential to impair the primary capability of the 718 network. 720 In addition to physical layer obstructions, the forms of attack that 721 allows disruption of network traffic forwarding include [Karlof2003] 723 o Selective forwarding attacks; 725 o Wormhole attacks; 727 o Sinkhole attacks. 729 For reference, Figure 2 depicts the above listed three types of 730 attacks. 732 |Node_1|--(msg1|msg2|msg3)-->|Attacker|--(msg1|msg3)-->|Node_2| 734 (a) Selective Forwarding 736 |Node_1|-------------Unreachable---------x|Node_2| 737 | ^ 738 | Private Link | 739 '-->|Attacker_1|===========>|Attacker_2|--' 741 (b) Wormhole 743 |Node_1| |Node_4| 744 | | 745 `--------. | 746 Falsify as \ | 747 Good Link \ | | 748 To Node_5 \ | | 749 \ V V 750 |Node_2|-->|Attacker|--Not Forwarded---x|Node_5| 751 ^ ^ \ 752 | | \ Falsify as 753 | | \Good Link 754 / | To Node_5 755 ,-------' | 756 | | 757 |Node_3| |Node_i| 759 (c) Sinkhole 761 Figure 2: Selective Forwarding, Wormhole, and Sinkhole Attacks 763 7.3. Communications Resource Disruption 765 Attacks mounted against the communication channel resource assets 766 needed by the routing protocol can be used as a means of disrupting 767 its operation. However, while various forms of Denial of Service 768 (DoS) attacks on the underlying transport subsystem will affect 769 routing protocol exchanges and operation (for example physical layer 770 RF jamming in a wireless network or link layer attacks), these 771 attacks cannot be countered by the routing protocol. As such, the 772 threats to the underlying transport network that supports routing is 773 considered beyond the scope of the current document. Nonetheless, 774 attacks on the subsystem will affect routing operation and so must be 775 directly addressed within the underlying subsystem and its 776 implemented protocol layers. 778 7.4. Node Resource Exhaustion 780 A potential threat consequence can arise from attempts to overload 781 the node resource asset by initiating exchanges that can lead to the 782 exhaustion of processing, memory, or energy resources. The 783 establishment and maintenance of routing neighbors opens the routing 784 process to engagement and potential acceptance of multiple 785 neighboring peers. Association information must be stored for each 786 peer entity and for the wireless network operation provisions made to 787 periodically update and reassess the associations. An introduced 788 proliferation of apparent routing peers can therefore have a negative 789 impact on node resources. 791 Node resources may also be unduly consumed by attackers attempting 792 uncontrolled topology peering or routing exchanges, routing replays, 793 or the generating of other data traffic floods. Beyond the 794 disruption of communications channel resources, these consequences 795 may be able to exhaust node resources only where the engagements are 796 able to proceed with the peer routing entities. Routing operation 797 and network forwarding functions can thus be adversely impacted by 798 node resources exhaustion that stems from attacks that include: 800 o Identity (including Sybil) attacks; 802 o Routing information replay attacks; 804 o HELLO flood attacks; 806 o Overload attacks. 808 8. Countermeasures 810 By recognizing the characteristics of LLNs that may impact routing, 811 this analysis provides the basis for developing capabilities within 812 ROLL protocols to deter the identified attacks and mitigate the 813 threats. The following subsections consider such countermeasures by 814 grouping the attacks according to the classification of the ISO 815 7498-2 model so that associations with the necessary security 816 services are more readily visible. However, the considerations here 817 are more systematic than confined to means available only within 818 routing; the next section will then distill and make recommendations 819 appropriate for a secured ROLL protocol. 821 8.1. Confidentiality Attack Countermeasures 823 Attacks to disclosure routing information may be mounted at the level 824 of the routing information assets, at the points of access associated 825 with routing exchanges between nodes, or through device interface 826 access. To gain access to routing/topology information, the attacker 827 may rely on a compromised node that deliberately exposes the 828 information during the routing exchange process, may rely on passive 829 sniffing or traffic analysis, or may attempt access through a 830 component or device interface of a tampered routing node. 832 8.1.1. Countering Deliberate Exposure Attacks 834 A deliberate exposure attack is one in which an entity that is party 835 to the routing process or topology exchange allows the routing/ 836 topology information or generated route information to be exposed to 837 an unauthorized entity. 839 A prerequisite to countering this attack is to ensure that the 840 communicating nodes are authenticated prior to data encryption 841 applied in the routing exchange. Authentication ensures that the 842 nodes are who they claim to be even though it does not provide an 843 indication of whether the node has been compromised. 845 To mitigate the risk of deliberate exposure, the process that 846 communicating nodes use to establish session keys must be peer-to- 847 peer (i.e., between the routing initiating and responding nodes). 848 This helps ensure that neither node is exchaning routing information 849 with another peer without the knowledge of both communicating 850 peerscan. For a deliberate exposure attack to succeed, the comprised 851 node will need to more overt and take independent actions in order to 852 disclose the routing information to 3rd party. 854 Note that the same measures which apply to securing routing/topology 855 exchanges between operational nodes must also extend to field tools 856 and other devices used in a deployed network where such devices can 857 be configured to participate in routing exchanges. 859 8.1.2. Countering Sniffing Attacks 861 A sniffing attack seeks to breach routing confidentiality through 862 passive, direct analysis and processing of the information exchanges 863 between nodes. A sniffing attack in an LLN that is not based on a 864 physical device compromise will rely on the attacker attempting to 865 directly derive information from the over-the-shared-medium routing/ 866 topology communication exchange (neighbor discovery exchanges may of 867 necessity be conducted in the clear thus limiting the extent to which 868 the information can be kept confidential). 870 Sniffing attacks can be directly countered through the use of data 871 encryption for all routing exchanges. Only when a validated and 872 authenticated node association is completed will routing exchange be 873 allowed to proceed using established session keys and an agreed 874 encryption algorithm. The strength of the encryption algorithm and 875 session key sizes will determine the minimum requirement for an 876 attacker mounting this passive security attack. The possibility of 877 incorporating options for security level and algorithms is further 878 considered in Section 9.5. Because of the resource constraints of 879 LLN devices, symmetric (private) key encryption will provide the best 880 trade-off in terms of node and channel resource overhead and the 881 level of security achieved. This will of course not preclude the use 882 of asymmetric (public) key encryption during the session key 883 establishment phase. 885 As with the key establishment process, data encryption must include 886 an authentication prerequisite to ensure that each node is 887 implementing a level of security that prevents deliberate or 888 inadvertent exposure. The authenticated key establishment will 889 ensure that confidentiality is not compromised by providing the 890 information to an unauthorized entity (see also [Huang2003]). 892 Based on the current state of the art, a minimum 128-bit key length 893 should be applied where robust confidentiality is demanded for 894 routing protection. This session key shall be applied in conjunction 895 with an encryption algorithm that has been publicly vetted and where 896 applicable approved for the level of security desired. Algorithms 897 such as the Advanced Encryption Standard (AES) [FIPS197], adopted by 898 the U.S. government, or Kasumi-Misty [Kasumi3gpp], adopted by the 899 3GPP 3rd generation wireless mobile consortium, are examples of 900 symmetric-key algorithms capable of ensuring robust confidentiality 901 for routing exchanges. The key length, algorithm and mode of 902 operation will be selected as part of the overall security trade-off 903 that also achieves a balance with the level of confidentiality 904 afforded by the physical device in protecting the routing assets (see 905 Section 8.1.4 below). 907 As with any encryption algorithm, the use of ciphering 908 synchronization parameters and limitations to the usage duration of 909 established keys should be part of the security specification to 910 reduce the potential for brute force analysis. 912 8.1.3. Countering Traffic Analysis 914 Traffic analysis provides an indirect means of subverting 915 confidentiality and gaining access to routing information by allowing 916 an attacker to indirectly map the connectivity or flow patterns 917 (including link-load) of the network from which other attacks can be 918 mounted. The traffic analysis attack on an LLN, especially one 919 founded on shared medium, is passive and relies on the ability to 920 read the immutable source/destination routing information that must 921 remain unencrypted to permit network routing. Alternatively, attacks 922 can be mounted through the injection of unauthorized discovery 923 traffic into the network. By implementing authentication measures 924 between communicating nodes, active traffic analysis attacks can be 925 prevented within the LLN thereby reducing confidentiality 926 vulnerabilities to those associated with passive analysis. 928 One way in which passive traffic analysis attacks can be muted is 929 through the support of load balancing that allows traffic to a given 930 destination to be sent along diverse routing paths. Where the 931 routing protocol supports load balancing along multiple links at each 932 node, the number of routing permutations in a wide area network 933 surges thus increasing the cost of traffic analysis. Network 934 analysis through this passive attack will require a wider array of 935 analysis points and additional processing on the part of the 936 attacker. Note however that where network traffic is dispersed as a 937 countermeasure there may be implications beyond routing with regard 938 to general traffic confidentiality. Another approach to countering 939 passive traffic analysis could be for nodes to maintain constant 940 amount of traffic to different destinations through the generation of 941 arbitrary traffic flows; the drawback of course would be the 942 consequent overhead. In LLNs, the diverse radio connectivity and 943 dynamic links (including potential frequency hopping), or a complex 944 wiring system hidden from sight, will help to further mitigate 945 traffic analysis attacks when load balancing is also implemented. 947 The only means of fully countering a traffic analysis attack is 948 through the use of tunneling (encapsulation) where encryption is 949 applied across the entirety of the original packet source/destination 950 addresses. With tunneling there is a further requirement that the 951 encapsulating intermediate nodes apply an additional layer of routing 952 so that traffic arrives at the destination through dynamic routes. 953 For some LLNs, memory and processing constraints as well as the 954 limitations of the communication channel will preclude both the 955 additional routing traffic overhead and the node implementation 956 required for tunneling countermeasures to traffic analysis. 958 8.1.4. Countering Physical Device Compromise 960 Section 5 identified that many threats to the routing functionality 961 may involve compromised devices. For the sake of completeness, this 962 subsection examines how to counter physical device compromise, 963 without restricting the consideration to only those methods and 964 apparatuses available to an LLN routing protocol. 966 Given the distributed nature of LLNs and the varying environment of 967 deployed devices, confidentiality of routing assets and points of 968 access may rely heavily on the security of the routing devices. One 969 means of precluding attacks on the physical device is to prevent 970 physical access to the node through other external security means. 971 However, given the environment in which many LLNs operate, preventing 972 unauthorized access to the physical device cannot be assured. 973 Countermeasures must therefore be employed at the device and 974 component level so that routing/topology or neighbor information and 975 stored route information cannot be accessed even if physical access 976 to the node is obtained. 978 With the physical device in the possession of an attacker, 979 unauthorized information access can be attempted by probing internal 980 interfaces or device components. Device security must therefore move 981 to preventing the reading of device processor code or memory 982 locations without the appropriate security keys and in preventing the 983 access to any information exchanges occurring between individual 984 components. Information access will then be restricted to external 985 interfaces in which confidentiality, integrity, and authentication 986 measures can be applied. 988 To prevent component information access, deployed routing devices 989 must ensure that their implementation avoids address or data buses 990 being connected to external general purpose input/output (GPIO) pins. 991 Beyond this measure, an important component interface to be protected 992 against attack is the Joint Test Action Group (JTAG) [IEEE1149.1] 993 interface used for component and populated circuit board testing 994 after manufacture. To provide security on the routing devices, 995 components should be employed that allow fuses on the JTAG interfaces 996 to be blown to disable access. This will raise the bar on 997 unauthorized component information access within a captured device. 999 At the device level a key component information exchange is between 1000 the microprocessor and its associated external memory. While 1001 encryption can be implemented to secure data bus exchanges, the use 1002 of integrated physical packaging which avoids inter-component 1003 exchanges (other than secure external device exchanges) will increase 1004 routing security against a physical device interface attack. With an 1005 integrated package and disabled internal component interfaces, the 1006 level of physical device security can be controlled by managing the 1007 degree to which the device packaging is protected against expert 1008 physical decomposition and analysis. 1010 The device package should be hardened such that attempts to remove 1011 the integrated components will result in damage to access interfaces, 1012 ports or pins that prevent retrieval of code or stored information. 1013 The degree of Very Large Scale Integration (VLSI) or Printed Circuit 1014 Board (PCB) package security through manufacture can be selected as a 1015 trade-off or desired security consistent with the level of security 1016 achieved by measures applied for other routing assets and points of 1017 access. With package hardening and restricted component access 1018 countermeasures, the security level will be raised to that provided 1019 by measures employed at the external communications interfaces. 1021 Another area of node interface vulnerability is that associated with 1022 interfaces provided for remote software or firmware upgrades. This 1023 may impact both routing information and routing/topology exchange 1024 security where it leads to unauthorized upgrade or change to the 1025 routing protocol running on a given node as this type of attack can 1026 allow for the execution of compromised or intentionally malicious 1027 routing code on multiple nodes. Countermeasures to this device 1028 interface confidentiality attack needs to be addressed in the larger 1029 context of node remote access security. This will ensure not only 1030 the authenticity of the provided code (including routing protocol) 1031 but that the process is initiated by an authorized (authenticated) 1032 entity. For example, digital signing of firmware by an authorized 1033 entity will provide an appropriate countermeasure. 1035 The above identified countermeasures against attacks on routing 1036 information confidentiality through internal device interface 1037 compromise must be part of the larger LLN system security as they 1038 cannot be addressed within the routing protocol itself. Similarly, 1039 the use of field tools or other devices that allow explicit access to 1040 node information must implement security mechanisms to ensure that 1041 routing information can be protected against unauthorized access. 1042 These protections will also be external to the routing protocol and 1043 hence not part of ROLL. 1045 8.1.5. Countering Remote Device Access Attacks 1047 Where LLN nodes are deployed in the field, measures are introduced to 1048 allow for remote retrieval of routing data and for software or field 1049 upgrades. These paths create the potential for a device to be 1050 remotely accessed across the network or through a provided field 1051 tool. In the case of network management a node can be directly 1052 requested to provide routing tables and neighbor information. 1054 To ensure confidentiality of the node routing information against 1055 attacks through remote access, any local or remote device requesting 1056 routing information must be authenticated to ensure authorized 1057 access. Since remote access is not invoked as part of a routing 1058 protocol security of routing information stored on the node against 1059 remote access will not be addressable as part of the routing 1060 protocol. 1062 8.2. Integrity Attack Countermeasures 1064 Integrity attack countermeasures address routing information 1065 manipulation, as well as node identity and routing information 1066 misuse. Manipulation can occur in the form of falsification attack 1067 and physical compromise. To be effective, the following development 1068 considers the two aspects of falsification, namely, the unauthorized 1069 modifications and the overclaiming and misclaiming content. The 1070 countering of physical compromise was considered in the previous 1071 section and is not repeated here. With regard to misuse, there are 1072 two types of attacks to be deterred, identity attacks and replay 1073 attacks. 1075 8.2.1. Countering Unauthorized Modification Attacks 1077 Unauthorized modifications may occur in the form of altering the 1078 message being transferred or the data stored. Therefore, it is 1079 necessary to ensure that only authorized nodes can change the portion 1080 of the information that is allowed to be mutable, while the integrity 1081 of the rest of the information is protected, e.g., through well- 1082 studied cryptographic mechanisms. 1084 Unauthorized modifications may also occur in the form of insertion or 1085 deletion of messages during protocol changes. Therefore, the 1086 protocol needs to ensure the integrity of the sequence of the 1087 exchange sequence. 1089 The countermeasure to unauthorized modifications needs to: 1091 o implement access control on storage; 1093 o provide data integrity service to transferred messages and stored 1094 data; 1096 o include sequence number under integrity protection. 1098 8.2.2. Countering Overclaiming and Misclaiming Attacks 1100 Both overclaiming and misclaiming aim to introduce false routes or 1101 topology that would not be generated by the network otherwise, while 1102 there are not necessarily unauthorized modifications to the routing 1103 messages or information. The requisite for a counter is the 1104 capability to determine unreasonable routes or topology. 1106 The counter to overclaiming and misclaiming may employ: 1108 o comparison with historical routing/topology data; 1109 o designs which restrict realizable network topologies. 1111 8.2.3. Countering Identity (including Sybil) Attacks 1113 Identity attacks, sometimes simply called spoofing, seek to gain or 1114 damage assets whose access is controlled through identity. In 1115 routing, an identity attacker can illegitimately participate in 1116 routing exchanges, distribute false routing information, or cause an 1117 invalid outcome of a routing process. 1119 A perpetrator of Sybil attacks assumes multiple identities. The 1120 result is not only an amplification of the damage to routing, but 1121 extension to new areas, e.g., where geographic distribution is 1122 explicitly or implicitly an asset to an application running on the 1123 LLN, for example, the LBR in a P2MP or MP2P LLN. 1125 The countering of identity attacks need to ensure the authenticity 1126 and liveliness of the parties of a message exchange. The means may 1127 be through the use of shared key- or public key-based authentication 1128 scheme. On the one hand, the large-scale nature of the LLNs makes 1129 the network-wide shared key scheme undesirable from a security 1130 perspective; on the other hand, public-key based approaches generally 1131 require more computational resources. Each system will need to make 1132 trade-off decisions based on its security requirements. As an 1133 example, [Wander2005] compared the energy consumption between two 1134 public-key algorithms on a low-power microcontroller, with reference 1135 to a symmetric-key algorithm and a hash algorithm. 1137 8.2.4. Countering Routing Information Replay Attacks 1139 In routing, message replay can result in false topology and/or 1140 routes. The counter of replay attacks needs to ensure the freshness 1141 of the message. On the one hand, there are a number of mechanisms 1142 commonly used for countering replay, e.g., with a counter. On the 1143 other hand, the choice should take into account how a particular 1144 mechanism is made available in an LLN. For example, many LLNs have a 1145 central source of time and have it distributed by relaying, such that 1146 secured time distribution becomes a prerequisite of using 1147 timestamping to counter replay. 1149 8.2.5. Countering Byzantine Routing Information Attacks 1151 Where a node is captured or compromised but continues to operate for 1152 a period with valid network security credentials, the potential 1153 exists for routing information to be manipulated. This compromise of 1154 the routing information could thus exist in spite of security 1155 countermeasures that operate between the peer routing devices. 1157 Consistent with the end-to-end principle of communications, such an 1158 attack can only be fully addressed through measures operating 1159 directly between the routing entities themselves or by means of 1160 external entities able to access and independently analyze the 1161 routing information. Verification of the authenticity and liveliness 1162 of the routing entities can therefore only provide a limited counter 1163 against internal (Byzantine) node attacks. 1165 For link state routing protocols where information is flooded with, 1166 for example, areas (OSPF [RFC2328]) or levels (ISIS [RFC1142]), 1167 countermeasures can be directly applied by the routing entities 1168 through the processing and comparison of link state information 1169 received from different peers. By comparing the link information 1170 from multiple sources decisions can be made by a routing node or 1171 external entity with regard to routing information validity; see 1172 Chapter 2 of [Perlman1988] for a discussion on flooding attacks. 1174 For distance vector protocols where information is aggregated at each 1175 routing node it is not possible for nodes to directly detect 1176 Byzantine information manipulation attacks from the routing 1177 information exchange. In such cases, the routing protocol must 1178 include and support indirect communications exchanges between non- 1179 adjacent routing peers to provide a secondary channel for performing 1180 routing information validation. S-RIP [Wan2004] is an example of the 1181 implementation of this type of dedicated routing protocol security 1182 where the correctness of aggregate distance vector information can 1183 only be validated by initiating confirmation exchanges directly 1184 between nodes that are not routing neighbors. 1186 Alternatively, an entity external to the routing protocol would be 1187 required to collect and audit routing information exchanges to detect 1188 the Byzantine attack. In the context of the current security 1189 analysis, any protection against Byzantine routing information 1190 attacks will need to be directly included within the mechanisms of 1191 the ROLL routing protocol. This can be implemented where such an 1192 attack is considered relevant even within the physical device 1193 protections discussed in Section 8.1.4. 1195 8.3. Availability Attack Countermeasures 1197 As alluded to before, availability requires that routing information 1198 exchanges and forwarding mechanisms be available when needed so as to 1199 guarantee proper functioning of the network. This may, e.g., include 1200 the correct operation of routing information and neighbor state 1201 information exchanges, among others. We will highlight the key 1202 features of the security threats along with typical countermeasures 1203 to prevent or at least mitigate them. We will also note that an 1204 availability attack may be facilitated by an identity attack as well 1205 as a replay attack, as was addressed in Section 8.2.3 and 1206 Section 8.2.4, respectively. 1208 8.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 1210 HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing 1211 attacks are different but highly related forms of attacking an LLN. 1212 They essentially lead nodes to believe that suitable routes are 1213 available even though they are not and hence constitute a serious 1214 availability attack. 1216 The origin of facilitating a HELLO flood attack lies in the fact that 1217 many routing protocols require nodes to send HELLO packets either 1218 upon joining or in regular intervals so as to announce or confirm 1219 their existence to the network. Those nodes that receive the HELLO 1220 packet assume that they are indeed neighbors. 1222 With this in mind, a malicious node can send or replay HELLO packets 1223 using, e.g., a higher transmission power. That creates the false 1224 illusion of being a neighbor to an increased number of nodes in the 1225 network, thereby effectively increasing its unidirectional 1226 neighborhood cardinality. The high quality of the falsely advertised 1227 link may coerce nodes to route data via the malicious node. However, 1228 those affected nodes, for which the malicious node is in fact 1229 unreachable, never succeed in their delivery and the packets are 1230 effectively dropped. The symptoms are hence similar to those of a 1231 sinkhole, wormhole and selective forwarding attack. 1233 A malicious HELLO flood attack clearly distorts the network topology. 1234 It thus affects protocols building and maintaining the network 1235 topology as well as routing protocols as such, since the attack is 1236 primarily targeted on protocols that require sharing of information 1237 for topology maintenance or flow control. 1239 To counter HELLO flood attacks, several mutually non-exclusive 1240 methods are feasible: 1242 o restricting neighborhood cardinality; 1244 o facilitating multipath routing; 1246 o verifying bidirectionality. 1248 Restricting the neighborhood cardinality prevents malicious nodes 1249 from having an extended set of neighbors beyond some tolerated 1250 threshold and thereby preventing topologies to be built where 1251 malicious nodes have a false neighborhood set. Furthermore, as shown 1252 in [I-D.suhopark-hello-wsn], if the routing protocol supports 1253 multiple paths from a sensing node towards several LBRs then HELLO 1254 flood attacks can also be diminished; however, the energy-efficiency 1255 of such approach is clearly sub-optimal. Finally, verifying that the 1256 link is truly bidirectional by means of, e.g., an ACK handshake and 1257 appropriate security measures ensures that a communication link is 1258 only established if not only the affected node is within range of the 1259 malicious node but also vice versa. Whilst this does not really 1260 eliminate the problem of HELLO flooding, it greatly reduces the 1261 number of affected nodes and the probability of such an attack 1262 succeeding. 1264 As for the latter, the adversary may spoof the ACK messages to 1265 convince the affected node that the link is truly bidirectional and 1266 thereupon drop, tunnel or selectively forward messages. Such ACK 1267 spoofing attack is possible if the malicious node has a receiver 1268 which is significantly more sensitive than that of a normal node, 1269 thereby effectively extending its range. Since an ACK spoofing 1270 attack facilitates a HELLO flood attack, similar countermeasure are 1271 applicable here. Viable counter and security measures for both 1272 attacks have been exposed in [I-D.suhopark-hello-wsn] 1274 8.3.2. Countering Overload Attacks 1276 Overload attacks are a form of DoS attack in that a malicious node 1277 overloads the network with irrelevant traffic, thereby draining the 1278 nodes' energy store more quickly, when the nodes rely on batteries or 1279 energy scavenging. It thus significantly shortens the lifetime of 1280 networks of energy-constrained nodes and constitutes another serious 1281 availability attack. 1283 With energy being one of the most precious assets of LLNs, targeting 1284 its availability is a fairly obvious attack. Another way of 1285 depleting the energy of an LLN node is to have the malicious node 1286 overload the network with irrelevant traffic. This impacts 1287 availability since certain routes get congested which: 1289 o renders them useless for affected nodes and data can hence not be 1290 delivered; 1292 o makes routes longer as shortest path algorithms work with the 1293 congested network; 1295 o depletes battery and energy scavenging nodes quicker and thus 1296 shortens the network's availability at large. 1298 Overload attacks can be countered by deploying a series of mutually 1299 non-exclusive security measures: 1301 o introduce quotas on the traffic rate each node is allowed to send; 1303 o isolate nodes which send traffic above a certain threshold based 1304 on system operation characteristics; 1306 o allow only trusted data to be received and forwarded. 1308 As for the first one, a simple approach to minimize the harmful 1309 impact of an overload attack is to introduce traffic quotas. This 1310 prevents a malicious node from injecting a large amount of traffic 1311 into the network, even though it does not prevent said node from 1312 injecting irrelevant traffic at all. Another method is to isolate 1313 nodes from the network at the network layer once it has been detected 1314 that more traffic is injected into the network than allowed by a 1315 prior set or dynamically adjusted threshold. Finally, if 1316 communication is sufficiently secured, only trusted nodes can receive 1317 and forward traffic which also lowers the risk of an overload attack. 1319 Receiving nodes that validate signatures and sending nodes that 1320 encrypt messages need to be cautious of cryptographic processing 1321 usage when validating signatures and encrypting messages. Where 1322 feasible, certificates should be validated prior to use of the 1323 associated keys to counter potential resource overloading attacks. 1324 The associated design decision needs to also consider that the 1325 validation process requires resources and thus itself could be 1326 exploited for attacks. Alternatively, resource management limits can 1327 be placed on routing security processing events (see the comment in 1328 Section 6, paragraph 4, of [RFC5751]). 1330 8.3.3. Countering Selective Forwarding Attacks 1332 Selective forwarding attacks are another form of DoS attack which 1333 impacts the routing path availability. 1335 An insider malicious node basically blends neatly in with the network 1336 but then may decide to forward and/or manipulate certain packets. If 1337 all packets are dropped, then this attacker is also often referred to 1338 as a "black hole". Such a form of attack is particularly dangerous 1339 if coupled with sinkhole attacks since inherently a large amount of 1340 traffic is attracted to the malicious node and thereby causing 1341 significant damage. In a shared medium, an outside malicious node 1342 would selectively jam overheard data flows, where the thus caused 1343 collisions incur selective forwarding. 1345 Selective Forwarding attacks can be countered by deploying a series 1346 of mutually non-exclusive security measures: 1348 o multipath routing of the same message over disjoint paths; 1350 o dynamically selecting the next hop from a set of candidates. 1352 The first measure basically guarantees that if a message gets lost on 1353 a particular routing path due to a malicious selective forwarding 1354 attack, there will be another route which successfully delivers the 1355 data. Such a method is inherently suboptimal from an energy 1356 consumption point of view; it is also suboptimal from a network 1357 utilization perspective. The second method basically involves a 1358 constantly changing routing topology in that next-hop routers are 1359 chosen from a dynamic set in the hope that the number of malicious 1360 nodes in this set is negligible. A routing protocol that allows for 1361 disjoint routing paths may also be useful. 1363 8.3.4. Countering Sinkhole Attacks 1365 In sinkhole attacks, the malicious node manages to attract a lot of 1366 traffic mainly by advertising the availability of high-quality links 1367 even though there are none [Karlof2003]. It hence constitutes a 1368 serious attack on availability. 1370 The malicious node creates a sinkhole by attracting a large amount 1371 of, if not all, traffic from surrounding neighbors by advertising in 1372 and outwards links of superior quality. Affected nodes hence eagerly 1373 route their traffic via the malicious node which, if coupled with 1374 other attacks such as selective forwarding, may lead to serious 1375 availability and security breaches. Such an attack can only be 1376 executed by an inside malicious node and is generally very difficult 1377 to detect. An ongoing attack has a profound impact on the network 1378 topology and essentially becomes a problem of flow control. 1380 Sinkhole attacks can be countered by deploying a series of mutually 1381 non-exclusive security measures: 1383 o use geographical insights for flow control; 1385 o isolate nodes which receive traffic above a certain threshold; 1387 o dynamically pick up next hop from set of candidates; 1389 o allow only trusted data to be received and forwarded. 1391 Whilst most of these countermeasures have been discussed before, the 1392 use of geographical information deserves further attention. 1393 Essentially, if geographic positions of nodes are available, then the 1394 network can assure that data is actually routed towards the intended 1395 destination and not elsewhere. On the other hand, geographic 1396 position is a sensitive information that has security and/or privacy 1397 consequences (see Section 9.1). 1399 8.3.5. Countering Wormhole Attacks 1401 In wormhole attacks at least two malicious nodes shortcut or divert 1402 the usual routing path by means of a low-latency out-of-band channel 1403 [Karlof2003]. This changes the availability of certain routing paths 1404 and hence constitutes a serious security breach. 1406 Essentially, two malicious insider nodes use another, more powerful, 1407 transmitter to communicate with each other and thereby distort the 1408 would-be-agreed routing path. This distortion could involve 1409 shortcutting and hence paralyzing a large part of the network; it 1410 could also involve tunneling the information to another region of the 1411 network where there are, e.g., more malicious nodes available to aid 1412 the intrusion or where messages are replayed, etc. In conjunction 1413 with selective forwarding, wormhole attacks can create race 1414 conditions which impact topology maintenance, routing protocols as 1415 well as any security suits built on "time of check" and "time of 1416 use". 1418 Wormhole attacks are very difficult to detect in general but can be 1419 mitigated using similar strategies as already outlined above in the 1420 context of sinkhole attacks. 1422 9. ROLL Security Features 1424 The assessments and analysis in Section 5 examined all areas of 1425 threats and attacks that could impact routing, and the 1426 countermeasures presented in Section 8 were reached without confining 1427 the consideration to means only available to routing. This section 1428 puts the results into perspective and provides a framework for 1429 addressing the derived set of security objectives that must be met by 1430 the routing protocol(s) specified by the ROLL Working Group. It 1431 bears emphasizing that the target here is a generic, universal form 1432 of the protocol(s) specified and the normative keywords are mainly to 1433 convey the relative level of importance or urgency of the features 1434 specified. 1436 In this view, 'MUST' is used to define the requirements that are 1437 specific to the routing protocol and that are essential for an LLN 1438 routing protocol to ensure that routing operation can be maintained. 1439 Adherence to MUST requirements is needed to directly counter attacks 1440 that can affect the routing operation (such as those that can impact 1441 maintained or derived routing/forwarding tables). 'SHOULD' is used 1442 to define requirements that counter indirect routing attacks where 1443 such attacks do not of themselves affect routing but can assist an 1444 attacker in focusing its attack resources to impact network operation 1445 (such as DoS targeting of key forwarding nodes). 'MAY' covers 1446 optional requirements that can further enhance security by increasing 1447 the space over which an attacker must operate or the resources that 1448 must be applied. While in support of routing security, where 1449 appropriate, these requirements may also be addressed beyond the 1450 network routing protocol at other system communications layers. 1452 The first part of this section, Section 9.1 to Section 9.3, is a 1453 prescription of ROLL security features of measures that can be 1454 addressed as part of the routing protocol itself. As routing is one 1455 component of an LLN system, the actual strength of the security 1456 services afforded to it should be made to conform to each system's 1457 security policy; how a design may address the needs of the urban, 1458 industrial, home automation, and building automation application 1459 domains also needs to be considered. The second part of this 1460 section, Section 9.4 and Section 9.5, discusses system security 1461 aspects that may impact routing but that also require considerations 1462 beyond the routing protocol, as well as potential approaches. 1464 If an LLN employs multicast and/or anycast, these alternative 1465 communications modes MUST be secured with the same routing security 1466 services specified in this section. Furthermore, irrespective of the 1467 modes of communication, nodes MUST provide adequate physical tamper 1468 resistance commensurate with the particular application domain 1469 environment to ensure the confidentiality, integrity, and 1470 availability of stored routing information. 1472 9.1. Confidentiality Features 1474 With regard to confidentiality, protecting the routing/topology 1475 information from unauthorized disclosure is not directly essential to 1476 maintaining the routing function. Breaches of confidentiality may 1477 lead to other attacks or the focusing of an attacker's resources (see 1478 Section 5.3) but does not of itself directly undermine the operation 1479 of the routing function. However, to protect against, and reduce 1480 consequences from other more direct attacks, routing information 1481 should be protected. Thus, a secured ROLL protocol: 1483 o MUST implement payload encryption; 1485 o MUST provide privacy when geographic information is used (see, 1486 e.g., [RFC3693]); 1488 o MAY provide tunneling; 1489 o MAY provide load balancing. 1491 Where confidentiality is incorporated into the routing exchanges, 1492 encryption algorithms and key lengths need to be specified in 1493 accordance with the level of protection dictated by the routing 1494 protocol and the associated application domain transport network. In 1495 terms of the life time of the keys, the opportunity to periodically 1496 change the encryption key increases the offered level of security for 1497 any given implementation. However, where strong cryptography is 1498 employed, physical, procedural, and logical data access protection 1499 considerations may have more significant impact on cryptoperiod 1500 selection than algorithm and key size factors. Nevertheless, in 1501 general, shorter cryptoperiods, during which a single key is applied, 1502 will enhance security. 1504 Given the mandatory protocol requirement to implement routing node 1505 authentication as part of routing integrity (see Section 9.2), key 1506 exchanges may be coordinated as part of the integrity verification 1507 process. This provides an opportunity to increase the frequency of 1508 key exchange and shorten the cryptoperiod as a complement to the key 1509 length and encryption algorithm required for a given application 1510 domain. For LLNs, the coordination of confidentiality key management 1511 with the implementation of node device authentication can thus reduce 1512 the overhead associated with supporting data confidentiality. If a 1513 new ciphering key is concurrently generated or updated in conjunction 1514 with the mandatory authentication exchange occurring with each 1515 routing peer association, signaling exchange overhead can be reduced. 1517 9.2. Integrity Features 1519 The integrity of routing information provides the basis for ensuring 1520 that the function of the routing protocol is achieved and maintained. 1521 To protect integrity, a secured ROLL protocol: 1523 o MUST provide and verify message integrity (including integrity of 1524 the encrypted message when confidentiality is applied); 1526 o MUST verify the authenticity and liveness of both principals of a 1527 connection (independent of the device interface over which the 1528 information is received or accessed); 1530 o MUST verify message sequence; 1532 o SHOULD incorporate protocol-specific parameter validity range 1533 checks, change increments, and message event frequency checks, 1534 etc. as a means of countering intentional or unintentional 1535 Byzantine threats; 1537 o MAY incorporate external consistency checking and auditing of 1538 routing information to protect against intentional or 1539 unintentional Byzantine-induced network anomalies. 1541 In conjunction with the integrity protection requirements, a secured 1542 ROLL protocol SHOULD log, against the offending node, any security 1543 failure that occurs after a valid integrity check. The record of 1544 such failures (as may result, for example, from incorrect security 1545 policy configuration) can provide the basis for nodes to avoid 1546 initiating routing access to the offender or be used for further 1547 system countermeasures in the case of potential insider attacks. All 1548 integrity security failures SHOULD be logged, where feasible, but 1549 cannot be reliably considered as countering against the offending 1550 source(s). 1552 Depending on the nature of the routing protocol, e.g., distance 1553 vector or link state, additional measures may be necessary when the 1554 validity of the routing information is of concern. In the most basic 1555 form, verification of routing peer authenticity and liveliness can be 1556 used to build a "chain of trust" along the path the routing 1557 information flows, such that network-wide information is validated 1558 through the concatenation of trust established at each individual 1559 routing peer exchange. This is particularly important in the case of 1560 distance vector-based routing protocols, where information is updated 1561 at intermediate nodes, In such cases, there are no direct means 1562 within routing for a receiver to verify the validity of the routing 1563 information beyond the current exchange; as such, nodes would need to 1564 be able to communicate and request information from non-adjacent 1565 peers (see [Wan2004]) to provide information integrity assurances. 1566 With link state-based protocols, on the other hand, routing 1567 information can be signed at the source thus providing a means for 1568 validating information that originates beyond a routing peer. 1569 Therefore, where necessary, a secured ROLL protocol MAY use security 1570 auditing mechanisms that are external to routing to verify the 1571 validity of the routing information content exchanged among routing 1572 peers. 1574 9.3. Availability Features 1576 Availability of routing information is linked to system and network 1577 availability which in the case of LLNs require a broader security 1578 view beyond the requirements of the routing entities (see 1579 Section 9.5). Where availability of the network is compromised, 1580 routing information availability will be accordingly affected. 1581 However, to specifically assist in protecting routing availability: 1583 o MAY restrict neighborhood cardinality; 1584 o MAY use multiple paths; 1586 o MAY use multiple destinations; 1588 o MAY choose randomly if multiple paths are available; 1590 o MAY set quotas to limit transmit or receive volume; 1592 o MAY use geographic information for flow control. 1594 9.4. Key Management 1596 The functioning of the routing security services requires keys and 1597 credentials. Therefore, even though not directly a ROLL security 1598 requirement, an LLN MUST have a process for initial key and 1599 credential configuration, as well as secure storage within the 1600 associated devices (including use of trusted platform modules where 1601 feasible and appropriate to the operating environment). Beyond 1602 initial credential configuration, an LLN is also encouraged to have 1603 automatic procedures for the revocation and replacement of the 1604 maintained security credentials. 1606 Peer associations and signaling exchanges require the generation and 1607 use of keys that MAY be derived from secret or public key exchanges 1608 as part of the routing signaling exchange or be directly obtained 1609 through device configuration. The routing protocol specification 1610 MUST include mechanisms to identify and synchronize these keys. 1612 For keys used to establish peer associations, the routing protocol(s) 1613 specified by the ROLL Working Group SHOULD employ key management 1614 mechanisms consistent with the guidelines given in [RFC4107]. Based 1615 on that RFC's recommendations, many LLNs, particularly given the 1616 intended scale and ad hoc device associations, will meet the 1617 requirement for supporting automated key management in conjunction 1618 with the routing protocol operation. These short-term, automated 1619 routing session keys may be derived from pre-stored security 1620 credentials or can be generated through key management mechanisms 1621 that are defined as part of the routing protocol exchange. Beyond 1622 the automated short-term keys, a long-term key management mechanism 1623 SHOULD also be defined for changing or updating the credentials from 1624 which short-term routing association key material is derived. 1626 The use of a public key infrastructure (PKI), where feasible, can be 1627 used to support authenticated short-term key management as well as 1628 the distribution of long-term routing security keying material. Note 1629 that where the option for a PKI is supported for security of the 1630 routing protocol itself, the routing protocol MUST include provisions 1631 for public key certificates to be included or referenced within 1632 routing messages to allow a node's public key to be shared with 1633 communicating peers. Even if the certificate itself is not 1634 distributed by the node, there needs to be a mechanism to inform the 1635 receiving node where to find the certificate and obtain associated 1636 validation information; see [RFC3029] for an example of the kind of 1637 localized PKI support that may be applied in a given LLN environment. 1638 Where PKI systems are not feasible, the key management system MUST 1639 support means for secure configuration, device authentication, and 1640 adherence to secure key wrapping principles for the secure 1641 distribution and update of device keys. 1643 LLN routing protocols SHOULD be designed to allow the use of existing 1644 and validated key management schemes. As part of the LLN 1645 optimization, these schemes may be independent of the routing 1646 protocol and part of the broader LLN system security specifications. 1647 Where the long-term key management is defined separately from the 1648 routing protocol security, LLN application domains can appropriately 1649 employ IETF-standard key management specifications. Established key 1650 management solutions such as IKEv2 [RFC5996] or MIKEY [RFC3830], 1651 which supports several alternative private, public, or Diffie-Hellman 1652 key distribution methods (see [RFC5197]), can thus be adapted for use 1653 in LLNs. For example, see [I-D.alexander-roll-mikey-lln-key-mgmt]. 1654 Group key management and distribution methods may also be developed 1655 based on the architecture principles defined in MSEC [RFC4046]. 1657 9.5. Consideration on Matching Application Domain Needs 1659 Providing security within an LLN requires considerations that extend 1660 beyond routing security to the broader LLN application domain 1661 security implementation. In other words, as routing is one component 1662 of an LLN system, the actual strength of the implemented security 1663 algorithms for the routing protocol MUST be made to conform to the 1664 system's target level of security. The development so far takes into 1665 account collectively the impacts of the issues gathered from 1666 [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. The following two 1667 subsections first consider from an architectural perspective how the 1668 security design of a ROLL protocol may be made to adapt to the four 1669 application domains, and then examine mechanisms and protocol 1670 operations issues. 1672 9.5.1. Security Architecture 1674 The first challenge for a ROLL protocol security design is to have an 1675 architecture that can adequately address a set of very diverse needs. 1676 It is mainly a consequence of the fact that there are both common and 1677 non-overlapping requirements from the four application domains, 1678 while, conceivably, each individual application will present yet its 1679 own unique constraints. 1681 For a ROLL protocol, the security requirements defined in Section 9.1 1682 to Section 9.4 can be addressed at two levels: 1) through measures 1683 implemented directly within the routing protocol itself and initiated 1684 and controlled by the routing protocol entities; or 2) through 1685 measures invoked on behalf of the routing protocol entities but 1686 implemented within the part of the network over which the protocol 1687 exchanges occur. 1689 Where security is directly implemented as part of the routing 1690 protocol the security requirements configured by the user (system 1691 administrator) will operate independently of the lower layers. 1692 OSPFv2 [RFC2328] is an example of such an approach in which security 1693 parameters are exchanged and assessed within the routing protocol 1694 messages. In this case, the mechanism may be, e.g., a header 1695 containing security material of configurable security primitives in 1696 the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec [RFC4301] is 1697 employed to secure the network, the included protocol-specific (OSPF 1698 or RIP) security elements are in addition to and independent of those 1699 at the network layer. In the case of LLNs or other networks where 1700 system security mandates protective mechanisms at other lower layers 1701 of the network, security measures implemented as part of the routing 1702 protocol will be redundant to security measures implemented elsewhere 1703 as part of the protocol stack. 1705 Security mechanisms built into the routing protocol can ensure that 1706 all desired countermeasures can be directly addressed by the protocol 1707 all the way to the endpoint of the routing exchange. In particular, 1708 routing protocol Byzantine attacks by a compromised node that retains 1709 valid network security credentials can only be detected at the level 1710 of the information exchanged within the routing protocol. Such 1711 attacks aimed at the manipulation of the routing information can only 1712 be fully addressed through measures operating directly between the 1713 routing entities themselves or external entities able to access and 1714 analyze the routing information (see discussion in Section 8.2.5). 1716 On the other hand, it is more desirable from an LLN device 1717 perspective that the ROLL protocol is integrated into the framework 1718 of an overall system architecture where the security facility may be 1719 shared by different applications and/or across layers for efficiency, 1720 and where security policy and configurations can be consistently 1721 specified. See, for example, considerations made in RIPng [RFC2080] 1722 or the approach presented in [Messerges2003]. 1724 Where the routing protocol is able to rely on security measures 1725 configured within other layers of the protocol stack, greater system 1726 efficiency can be realized by avoiding potentially redundant 1727 security. Relying on an open trust model [Messerges2003], the 1728 security requirements of the routing protocol can be more flexibly 1729 met at different layers of the transport network; measures that must 1730 be applied to protect the communications network are concurrently 1731 able to provide the needed routing protocol protection. 1733 For example, where a given security encryption scheme is deemed the 1734 appropriate standard for network confidentiality of data exchanges at 1735 the link layer, that level of security is directly provided to 1736 routing protocol exchanges across the local link. Similarly, where a 1737 given authentication procedure is stipulated as part of the standard 1738 required for authenticating network traffic, that security provision 1739 can then meet the requirement needed for authentication of routing 1740 exchanges. In addition, in the context of the different LLN 1741 application domains, the level of security specified for routing can 1742 and should be consistent with that considered appropriate for 1743 protecting the network within the given environment. 1745 A ROLL protocol MUST be made flexible by a design that offers the 1746 configuration facility so that the user (network administrator) can 1747 choose the security settings that match the application's needs. 1748 Furthermore, in the case of LLNs, that flexibility SHOULD extend to 1749 allowing the routing protocol security requirements to be met by 1750 measures applied at different protocol layers, provided the 1751 identified requirements are collectively met. 1753 Since Byzantine attackers that can affect the validity of the 1754 information content exchanged between routing entities can only be 1755 directly countered at the routing protocol level, the ROLL protocol 1756 MAY support mechanisms for verifying routing data validity that 1757 extend beyond the chain of trust created through device 1758 authentication. This protocol-specific security mechanism SHOULD be 1759 made optional within the protocol allowing it to be invoked according 1760 to the given routing protocol and application domain and as selected 1761 by the system user. All other ROLL security mechanisms needed to 1762 meet the above identified routing security requirements can be 1763 flexibly implemented within the transport network (at the IP network 1764 layer or higher or lower protocol layers(s)) according to the 1765 particular application domain and user network configuration. 1767 Based on device capabilities and the spectrum of operating 1768 environments it would be difficult for a single fixed security design 1769 to be applied to address the diversified needs of the urban, 1770 industrial, home, and building ROLL application domains, and 1771 foreseeable others, without forcing a very low common denominator set 1772 of requirements. On the other hand, providing four individual domain 1773 designs that attempt to a priori match each individual domain is also 1774 very unlikely to provide a suitable answer given the degree of 1775 network variability even within a given domain; furthermore, the type 1776 of link layers in use within each domain also influences the overall 1777 security. 1779 Instead, the framework implementation approach recommended is for 1780 optional, routing protocol-specific measures that can be applied 1781 separately from, or together with, flexible transport network 1782 mechanisms. Protocol-specific measures include the specification of 1783 valid parameter ranges, increments and/or event frequencies that can 1784 be verified by individual routing devices. In addition to deliberate 1785 attacks this allows basic protocol sanity checks against 1786 unintentional mis-configuration. Transport network mechanisms would 1787 include out-of-band communications that may be defined to allow an 1788 external entity to request and process individual device information 1789 as a means to effecting an external verification of the derived 1790 network routing information to identify the existence of intentional 1791 or unintentional network anomalies. 1793 This approach allows countermeasures against byzantine attackers to 1794 be applied in environments where applicable threats exist. At the 1795 same time, it allows routing protocol security to be supported 1796 through measures implemented within the transport network that are 1797 consistent with available system resources and commensurate and 1798 consistent with the security level and strength applied in the 1799 particular application domain networks. 1801 9.5.2. Mechanisms and Operations 1803 With an architecture allowing different configurations to meet the 1804 application domain needs, the task is then to find suitable 1805 mechanisms. For example, one of the main problems of synchronizing 1806 security states of sleepy nodes lies in difficulties in 1807 authentication; these nodes may not have received in time the most 1808 recent update of security material. Similarly, the issues of minimal 1809 manual configuration, prolonged rollout and delayed addition of 1810 nodes, and network topology changes also complicate security 1811 management. In many cases the ROLL protocol may need to bootstrap 1812 the authentication process and allow for a flexible expiration scheme 1813 of authentication credentials. This exemplifies the need for the 1814 coordination and interoperation between the requirements of the ROLL 1815 routing protocol and that of the system security elements. 1817 Similarly, the vulnerability brought forth by some special-function 1818 nodes, e.g., LBRs requires the assurance, particularly, of the 1819 availability of communication channels and node resources, or that 1820 the neighbor discovery process operates without undermining routing 1821 availability. 1823 There are other factors which are not part of a ROLL routing protocol 1824 but which can still affect its operation. These include elements 1825 such as weaker barrier to accessing the data or security material 1826 stored on the nodes through physical means; therefore, the internal 1827 and external interfaces of a node need to be adequate for guarding 1828 the integrity, and possibly the confidentiality, of stored 1829 information, as well as the integrity of routing and route generation 1830 processes. 1832 Figure 3 provides an overview of the larger context of system 1833 security and the relationship between ROLL requirements and measures 1834 and those that relate to the LLN system. 1836 Security Services for 1837 ROLL-Addressable 1838 Security Requirements 1839 | | 1840 +---+ +---+ 1841 Node_i | | Node_j 1842 _____v___ ___v_____ 1843 Specify Security / \ / \ Specify Security 1844 Requirements | Routing | | Routing | Requirements 1845 +---------| Protocol| | Protocol|---------+ 1846 | | Entity | | Entity | | 1847 | \_________/ \_________/ | 1848 | | | | 1849 |ROLL-Specified | | ROLL-Specified| 1850 ---Interface | | Interface--- 1851 | ...................................... | 1852 | : | | : | 1853 | : +-----+----+ +----+-----+ : | 1854 | : |Transport/| |Transport/| : | 1855 ____v___ : +>|Network | |Network |<+ : ___v____ 1856 / \ : | +-----+----+ +----+-----+ | : / \ 1857 | |-:-+ | | +-:-| | 1858 |Security| : +-----+----+ +----+-----+ : |Security| 1859 +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ 1860 | |Entity | : +-----+----+ +----+-----+ : |Entity | | 1861 | | |-:-+ | | +-:-| | | 1862 | \________/ : | +-----+----+ +----+-----+ | : \________/ | 1863 | : +>| Physical | | Physical |<+ : | 1864 Application : +-----+----+ +----+-----+ : Application 1865 Domain User : | | : Domain User 1866 Configuration : |__Comm. Channel_| : Configuration 1867 : : 1868 ...Protocol Stack..................... 1870 Figure 3: LLN Device Security Model 1872 10. IANA Considerations 1874 This memo includes no request to IANA. 1876 11. Security Considerations 1878 The analysis presented in this document provides security analysis 1879 and design guidelines with a scope limited to ROLL. Security 1880 services are identified as requirements for securing ROLL. The 1881 specific mechanisms to be used to deal with each threat is specified 1882 in link-layer and deployment specific applicability statements. 1884 12. Acknowledgments 1886 The authors would like to acknowledge the review and comments from 1887 Rene Struik and JP Vasseur. The authors would also like to 1888 acknowledge the guidance and input provided by the ROLL Chairs, David 1889 Culler, and JP Vasseur, and the Area Director Adrian Farrel. 1891 This document started out as a combined threat and solutions 1892 document. As a result of security review, the document was split up 1893 by ROLL co-Chair Michael Richardson and security Area Director Sean 1894 Turner as it went through the IETF publication process. The 1895 solutions to the threads are application and layer-2 specific, and 1896 have therefore been moved to the relevant applicability statements. 1898 13. References 1900 13.1. Normative References 1902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1903 Requirement Levels", BCP 14, RFC 2119, March 1997. 1905 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1906 Key Management", BCP 107, RFC 4107, June 2005. 1908 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1909 Internet Protocol", RFC 4301, December 2005. 1911 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1912 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1913 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1914 Lossy Networks", RFC 6550, March 2012. 1916 13.2. Informative References 1918 [FIPS197] "Federal Information Processing Standards Publication 197: 1919 Advanced Encryption Standard (AES)", US National Institute 1920 of Standards and Technology, Nov. 26 2001. 1922 [Huang2003] 1923 Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. 1924 Zhang, "Fast Authenticated Key Establishment Protocols for 1925 Self-Organizing Sensor Networks", in Proceedings of the 1926 2nd ACM International Conference on Wireless Sensor 1927 Networks and Applications, San Diego, CA, USA, pp. 141- 1928 150, Sept. 19 2003. 1930 [I-D.alexander-roll-mikey-lln-key-mgmt] 1931 Alexander, R. and T. Tsao, "Adapted Multimedia Internet 1932 KEYing (AMIKEY): An extension of Multimedia Internet 1933 KEYing (MIKEY) Methods for Generic LLN Environments", 1934 draft-alexander-roll-mikey-lln-key-mgmt-04 (work in 1935 progress), September 2012. 1937 [I-D.suhopark-hello-wsn] 1938 Park, S., "Routing Security in Sensor Network: HELLO Flood 1939 Attack and Defense", draft-suhopark-hello-wsn-00 (work in 1940 progress), December 2005. 1942 [IEEE1149.1] 1943 "IEEE Standard Test Access Port and Boundary Scan 1944 Architecture", IEEE-SA Standards Board, Jun. 14 2001. 1946 [Karlof2003] 1947 Karlof, C. and D. Wagner, "Secure routing in wireless 1948 sensor networks: attacks and countermeasures", Elsevier 1949 AdHoc Networks Journal, Special Issue on Sensor Network 1950 Applications and Protocols, 1(2):293-315, September 2003. 1952 [Kasumi3gpp] 1953 "3GPP TS 35.202 Specification of the 3GPP confidentiality 1954 and integrity algorithms; Document 2: Kasumi 1955 specification", 3GPP TSG SA3, 2009. 1957 [Messerges2003] 1958 Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, 1959 R., and E. Callaway, "Low-Power Security for Wireless 1960 Sensor Networks", in Proceedings of the 1st ACM Workshop 1961 on Security of Ad Hoc and Sensor Networks, Fairfax, VA, 1962 USA, pp. 1-11, Oct. 31 2003. 1964 [Myagmar2005] 1965 Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as 1966 a Basis for Security Requirements", in Proceedings of the 1967 Symposium on Requirements Engineering for Information 1968 Security (SREIS'05), Paris, France, pp. 94-102, Aug 1969 29, 2005. 1971 [Perlman1988] 1972 Perlman, N., "Network Layer Protocols with Byzantine 1973 Robustness", MIT LCS Tech Report, 429, 1988. 1975 [RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", 1976 RFC 1142, February 1990. 1978 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1979 January 1997. 1981 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1983 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1984 November 1998. 1986 [RFC3029] Adams, C., Sylvester, P., Zolotarev, M., and R. 1987 Zuccherato, "Internet X.509 Public Key Infrastructure Data 1988 Validation and Certification Server Protocols", RFC 3029, 1989 February 2001. 1991 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 1992 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 1994 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. 1995 Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 1996 August 2004. 1998 [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, 1999 "Multicast Security (MSEC) Group Key Management 2000 Architecture", RFC 4046, April 2005. 2002 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 2003 Routing Protocols", RFC 4593, October 2006. 2005 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 2006 Service Considerations", RFC 4732, December 2006. 2008 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 2009 RFC 4949, August 2007. 2011 [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of 2012 Various Multimedia Internet KEYing (MIKEY) Modes and 2013 Extensions", RFC 5197, June 2008. 2015 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2016 "Routing Requirements for Urban Low-Power and Lossy 2017 Networks", RFC 5548, May 2009. 2019 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2020 "Industrial Routing Requirements in Low-Power and Lossy 2021 Networks", RFC 5673, October 2009. 2023 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2024 Mail Extensions (S/MIME) Version 3.2 Message 2025 Specification", RFC 5751, January 2010. 2027 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2028 Routing Requirements in Low-Power and Lossy Networks", 2029 RFC 5826, April 2010. 2031 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2032 "Building Automation Routing Requirements in Low-Power and 2033 Lossy Networks", RFC 5867, June 2010. 2035 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2036 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2037 RFC 5996, September 2010. 2039 [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A 2040 Secure Distance Vector Routing Protocol", in Proceedings 2041 of the 2nd International Conference on Applied 2042 Cryptography and Network Security, Yellow Mountain, China, 2043 pp. 103-119, Jun. 8-11 2004. 2045 [Wander2005] 2046 Wander, A., Gura, N., Eberle, H., Gupta, V., and S. 2047 Shantz, "Energy analysis of public-key cryptography for 2048 wireless sensor networ", in the Proceedings of the Third 2049 IEEE International Conference on Pervasive Computing and 2050 Communications pp. 324-328, March 8-12 2005. 2052 [Yourdon1979] 2053 Yourdon, E. and L. Constantine, "Structured Design", 2054 Yourdon Press, New York, Chapter 10, pp. 187-222, 1979. 2056 Authors' Addresses 2058 Tzeta Tsao 2059 Cooper Power Systems 2060 910 Clopper Rd. Suite 201S 2061 Gaithersburg, Maryland 20878 2062 USA 2064 Email: tzeta.tsao@cooperindustries.com 2065 Roger K. Alexander 2066 Cooper Power Systems 2067 910 Clopper Rd. Suite 201S 2068 Gaithersburg, Maryland 20878 2069 USA 2071 Email: roger.alexander@cooperindustries.com 2073 Mischa Dohler 2074 CTTC 2075 Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 2076 Castelldefels, Barcelona 08860 2077 Spain 2079 Email: mischa.dohler@cttc.es 2081 Vanesa Daza 2082 Universitat Pompeu Fabra 2083 P/ Circumval.lacio 8, Oficina 308 2084 Barcelona 08003 2085 Spain 2087 Email: vanesa.daza@upf.edu 2089 Angel Lozano 2090 Universitat Pompeu Fabra 2091 P/ Circumval.lacio 8, Oficina 309 2092 Barcelona 08003 2093 Spain 2095 Email: angel.lozano@upf.edu