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