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