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