idnits 2.17.1 draft-tsao-roll-security-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (September 20, 2009) is 5330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-roll-building-routing-reqs-07 == Outdated reference: A later version (-11) exists of draft-ietf-roll-home-routing-reqs-08 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group T. Tsao, Ed. 3 Internet-Draft R. Alexander, Ed. 4 Intended status: Informational Eka Systems 5 Expires: March 24, 2010 M. Dohler, Ed. 6 CTTC 7 V. Daza, Ed. 8 A. Lozano, Ed. 9 Universitat Pompeu Fabra 10 September 20, 2009 12 A Security Framework for Routing over Low Power and Lossy Networks 13 draft-tsao-roll-security-framework-01 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 24, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document presents a security framework for routing over low 52 power and lossy networks. The development of the framework builds 53 upon previous work on routing security and adapts the security 54 assessments to the issues and constraints specific to low power and 55 lossy networks. A systematic approach is used in defining and 56 assessing the security threats and identifying applicable 57 countermeasures. These assessments provide the basis of the security 58 recommendations for incorporation into low power, lossy network 59 routing protocols. 61 Requirements Language 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [RFC2119]. 67 Table of Contents 69 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 72 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 73 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 74 3.3. Issues Specific to or Magnified in LLNs . . . . . . . . . 10 75 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 11 76 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 77 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 78 4.1.2. Routing Information (Routes and Network Topology) 79 Exposure . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 81 4.2.1. Routing Information Manipulation . . . . . . . . . . . 13 82 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 13 83 4.3. Threats and Attacks on Availability . . . . . . . . . . . 14 84 4.3.1. Routing Exchange Interference or Disruption . . . . . 14 85 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 14 86 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 87 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 15 88 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 89 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 16 90 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 16 91 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 92 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 18 93 5.1.4. Countering Physical Device Compromise . . . . . . . . 18 94 5.1.5. Countering Remote Device Access Attacks . . . . . . . 20 95 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 20 96 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 21 97 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 21 98 5.2.3. Countering Identity (including Sybil) Attacks . . . . 21 99 5.2.4. Countering Routing Information Replay Attacks . . . . 22 100 5.3. Availability Attack Countermeasures . . . . . . . . . . . 22 101 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing 102 Attacks . . . . . . . . . . . . . . . . . . . . . . . 22 103 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 24 104 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 25 105 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 25 106 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 26 107 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 27 108 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 27 109 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 27 110 6.3. Availability Features . . . . . . . . . . . . . . . . . . 27 111 6.4. Additional Related Features . . . . . . . . . . . . . . . 28 112 6.5. Consideration on Matching Application Domain Needs . . . . 28 113 6.5.1. Architecture . . . . . . . . . . . . . . . . . . . . . 28 114 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 29 116 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 117 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 118 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 120 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 121 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 124 1. Terminology 126 This document conforms to the terminology defined in 127 [I-D.ietf-roll-terminology], with the following additions. 129 Link Cost A quantification of chosen characteristics of a link. 131 Node A base unit of a network, e.g., a router or a host on a low 132 power and lossy network. 134 Routing Metric A function of link costs along routes, whose value 135 gives rise to preference of routing choices. 137 2. Introduction 139 In recent times, networked wireless devices have found an increasing 140 number of applications in various fields. Yet, for reasons ranging 141 from operational application to economics, these wireless devices are 142 often supplied with minimum physical resources, e.g., limited power 143 reserve, slow speed or low capability computation, or small memory 144 size. As a consequence, the resulting networks are more prone to 145 loss of traffic and other vulnerabilities. The proliferation of 146 these low power and lossy networks (LLNs), however, are drawing 147 efforts to examine and address their potential networking challenges. 149 This document presents a framework for securing routing over low 150 power and lossy networks (ROLL) through an analysis that starts from 151 the routing basics. The objective is two-fold. First, the framework 152 will be used to identify pertinent security issues. Second, it will 153 facilitate both the assessment of a protocol's security threats and 154 the identification of the necessary features for development of 155 secure protocols for ROLL. 157 The approach adopted in this effort proceeds in four steps, to 158 examine ROLL security issues, to analyze threats and attacks, to 159 consider the countermeasures, and then to make recommendations for 160 securing ROLL. The basis is found on identifying the assets and 161 points of access of routing and evaluating their security needs based 162 on the Confidentiality, Integrity, and Availability (CIA) model in 163 the context of LLN. 165 3. Considerations on ROLL Security 167 This section sets the stage for the development of the framework by 168 applying the systematic approach proposed in [Myagmar2005] to the 169 routing security problem, while also drawing references from other 170 reviews and assessments found in the literature, particularly, 171 [RFC4593] and [Karlof2003]. The subsequent subsections begin with a 172 focus on the elements of a generic routing process that is used to 173 establish routing assets and points of access of the routing 174 functionality. Next, the CIA security model is briefly described. 175 Then, consideration is given to issues specific to or magnified in 176 LLNs. 178 3.1. Routing Assets and Points of Access 180 An asset implies important system component (including information, 181 process, or physical resource), the access to, corruption or loss of 182 which adversely affects the system. In network routing, assets lie 183 in the routing information, routing process, and node's physical 184 resources. That is, the access to, corruption, or loss of these 185 elements adversely affects system routing. In network routing, a 186 point of access refers to the point of entry facilitating 187 communication with or other interaction with a system component in 188 order to use system resources to either manipulate information or 189 gain knowledge of the information contained within the system. 190 Security of the routing protocol must be focused on the assets of the 191 routing nodes and the points of access of the information exchanges 192 and information storage that may permit routing compromise. The 193 identification of routing assets and points of access hence provides 194 a basis for the identification of associated threats and attacks. 196 This subsection identifies assets and points of access of a generic 197 routing process with a level-0 data flow diagram. The use of the 198 data flow diagram allows for a clear, concise model of the routing 199 functionality; it also has the benefit of showing the manner in which 200 nodes participate in the routing process, thus providing context when 201 later threats and attacks are considered. The goal of the model is 202 to be as detailed as possible so that corresponding components and 203 mechanisms in an individual routing protocol can be readily 204 identified, but also to be as general as possible to maximize the 205 relevancy of this effort for the various existing and future 206 protocols. Nevertheless, there may be discrepancies, likely in the 207 form of additional elements, when the model is applied to some 208 protocols. For such cases, the analysis approach laid out in this 209 document should still provide a valid and illustrative path for their 210 security assessment. 212 Figure 1 shows that nodes participating in the routing process 213 transmit messages to determine their neighbors (neighbor discovery). 214 Using the neighboring relationships, routing protocols may exchange 215 network topology (including link-specific information) to generate 216 routes or may exchange routes directly as part of a routing exchange; 217 nodes which do not directly participate in the process with a given 218 node will get the route/topology information relayed from others. It 219 is likely that a node will store some or all of the routes and 220 topology information according to tradeoffs of node resources and 221 latency associated with the particular routing protocol. The nodes 222 use the derived routes for making forwarding decisions. 224 ................................................... 225 : : 226 : _________________ : 227 |Node_i|<------->(Neighbor Discovery)--->Neighbor Topology : 228 : ----------------- : 229 : | : 230 |Node_j|<------->(Route/Topology +--------+ : 231 : Exchange ) | : 232 : | V ______ : 233 : +---->(Route Generation)--->Routes : 234 : ------ : 235 : | : 236 : Routing on a Node Node_k | : 237 ................................................... 238 | 239 |Forwarding | 240 On Node_k |<------------------------------------------+ 242 Notation: 244 (Proc) A process Proc 246 ________ 247 DataBase A data storage DataBase 248 -------- 250 |Node_n| An external entity Node_n 252 -------> Data flow 254 Figure 1: Data Flow Diagram of a Generic Routing Process 256 It is seen from Figure 1 that 258 o Assets include 260 * routing and/or topology information; 261 * communication channel resources (bandwidth); 263 * node resources (computing capacity, memory, and remaining 264 energy); 266 * node identifiers (including node identity and ascribed 267 attributes such as relative or absolute node location). 269 o Points of access include 271 * neighbor discovery; 273 * route/topology exchange; 275 * node physical interfaces (including access to data storage). 277 A focus on the above list of assets and points of access enables a 278 more directed assessment of routing security. Indeed, the intention 279 is to be comprehensive; nonetheless, the discussions to follow on 280 physical related issues are not related to routing protocol design 281 but provided for reference since they do have direct consequences on 282 the security of routing. 284 3.2. The CIA Security Reference Model 286 At the conceptual level, security within an information system in 287 general and applied to ROLL in particular is concerned with the 288 primary issues of confidentiality, integrity, and availability. In 289 the context of ROLL: 291 Confidentiality 292 Confidentiality involves the protection of routing information 293 as well as routing neighbor maintenance exchanges so that only 294 authorized and intended network entities may view or access it. 295 Because of the wireless, and sometimes ad hoc, nature of the 296 network, confidentiality also extends to the neighbor state and 297 database information within the routing device since the 298 deployment of the network creates the potential for 299 unauthorized access to the physical devices themselves. 301 Integrity 302 Integrity, as a security principle, entails the protection of 303 routing information and routing neighbor maintenance exchanges, 304 as well as derived information maintained in the database, from 305 misuse or unauthorized and improper modification. In addition, 306 integrity also requires the authenticity of claimed identity in 307 the origin and destination of a message, access and removal of 308 data, execution of the routing process, and use of computing 309 and energy resources. 311 Availability 312 Availability ensures that routing information exchanges and 313 forwarding services need to be available when they are required 314 for the functioning of the serving network. Availability will 315 apply to maintaining efficient and correct operation of routing 316 and neighbor discovery exchanges (including needed information) 317 and forwarding services so as not to impair or limit the 318 network's central traffic flow function. 320 It is noted that, besides those captured in the CIA model, non- 321 repudiation is another security concern evaluated. With respect to 322 routing, non-repudiation will involve providing some ability to allow 323 traceability or network management review of participants of the 324 routing process including the ability to determine the events and 325 actions leading to a particular routing state. Non-repudiation 326 implies after the fact and thus relies on the logging or other 327 capture of on-going routing exchanges. Given the limited resources 328 of a node and potentially the communication channel, and considering 329 the operating mode associated with LLNs, routing transaction logging 330 or auditing process communication overhead will not be practical; as 331 such, non-repudiation is not further considered as a relevant ROLL 332 security issue. 334 Based upon the CIA model, a high-level assessment of the security 335 needs of the assets found in Section 3.1 shows that 337 o routing/topology information needs to be integrity protected, 338 maintained with confidentiality, and prevented from unauthorized 339 use; 341 o neighbor discovery process needs to operate without undermining 342 routing availability; 344 o routing/topology exchange process needs to ensure that the 345 participants are authenticated, the communication of information 346 is integrity protected and confidential; 348 o communication channels and node resources need to have their 349 availability maintained; 351 o the internal and external interfaces of a node need to be 352 protected to ensure that integrity and confidentiality of stored 353 information is maintained as well as the integrity of routing and 354 route generation processes is assured. 356 Each individual system's use and environment will dictate how the 357 above general assessments are applied, including the choices of 358 security services as well as the strengths of the mechanisms that 359 must be implemented. The next subsection brings LLN-related issues 360 to light. 362 3.3. Issues Specific to or Magnified in LLNs 364 The work [RFC5548], as well as three other ongoing efforts, 365 [I-D.ietf-roll-indus-routing-reqs], 366 [I-D.ietf-roll-home-routing-reqs], and 367 [I-D.ietf-roll-building-routing-reqs], have identified ROLL specific 368 requirements and constraints for the urban, industrial, home 369 automation, and building automation application domains, 370 respectively. The following is a list of observations and evaluation 371 of their impact on routing security considerations. 373 Limited energy reserve, memory, and processing resources 374 As a consequence of these constraints, there is an even more 375 critical need than usual for a careful trade study on which and 376 what level of security services are to be afforded during the 377 system design process. In addition, routing schemes based on 378 various metrics have been proposed, e.g., geographic location. 379 Transmission and exchanging such metrics may have security 380 and/or privacy concerns. 382 Large scale of rolled out network 383 The possibly numerous nodes to be deployed, as well as the 384 general level of expertise of the installers, make manual on- 385 site configuration unlikely. Prolonged rollout and delayed 386 addition of nodes, which may be from old inventory, over the 387 lifetime of the network, also complicate the operations of key 388 management. 390 Autonomous operations 391 Self-forming and self-organizing are commonly prescribed 392 requirements of ROLL. In other words, a ROLL protocol needs to 393 contain elements of ad hoc networking and cannot rely on manual 394 configuration for initialization or local filtering rules. 396 Highly directional traffic 397 Some types of LLNs see a high percentage of their total traffic 398 traverse between the nodes and the gateways where the LLNs 399 connect to wired networks. The special routing status of and 400 the greater volume of traffic near the gateways have routing 401 security consequences. 403 Unattended locations and limited physical security 404 Many applications have the nodes deployed in unattended or 405 remote locations; furthermore, the nodes themselves are often 406 built with minimal physical protection. These constraints 407 lower the barrier of accessing the data or security material 408 stored on the nodes through physical means. 410 Support for mobility 411 On the one hand, only a number of applications require the 412 support of mobile nodes, e.g., a home LLN that includes nodes 413 on wearable health care devices or an industry LLN that 414 includes nodes on cranes and vehicles. On the other hand, if a 415 routing protocol is indeed used in such applications, it will 416 clearly need to have corresponding security mechanisms. 418 Support for multicast and anycast 419 ROLL support for multicast and anycast is called out chiefly 420 for large-scale networks. As these are relatively new routing 421 technologies, there has been an ongoing effort devoted to their 422 security mechanisms, e.g., from the IETF Multicast Security 423 working group. However, the threat model and attack analysis 424 are still areas not fully evaluated, and hence their impact is 425 not yet fully understood, whether in a wired, wireless, or LLN. 427 The above list considers how a LLN's physical constraints, size, 428 operations, and varieties of application areas may impact security. 429 It is noted here also that LLNs commonly have the majority, if not 430 all, of their nodes equipped to route. One of the consequences is 431 that the distinction between the link and network layers become 432 artificial in some respects. Similarly, the distinction between a 433 host and a router is blurred, especially when the set of applications 434 running on a node is small. The continued evolution of ROLL and its 435 security functionality requirements need close attention. 437 4. Threats and Attacks 439 This section outlines general categories of threats under the CIA 440 model and highlights the specific attacks in each of these categories 441 for ROLL. As defined in [RFC4949], a threat is "a potential for 442 violation of security, which exists when there is a circumstance, 443 capability, action, or event that could breach security and cause 444 harm." An attack is "an assault on system security that derives from 445 an intelligent threat, i.e., an intelligent act that is a deliberate 446 attempt (especially in the sense of a method or technique) to evade 447 security services and violate the security policy of a system." 449 The subsequent subsections consider the threats and their realizing 450 attacks that can cause security breaches under the CIA model to the 451 assets identified in Section 3.1. The analysis steps through the 452 security concerns of each routing asset and looks at the attacks that 453 can exploit points of access. The manifestation of the attacks is 454 assumed to be from either inside or outside attackers, whose 455 capabilities may be limited to node-equivalent or more sophisticated 456 computing platforms. 458 4.1. Threats and Attacks on Confidentiality 460 The assessment in Section 3.2 indicates that information assets are 461 exposed to confidentiality threats from all points of access. 463 4.1.1. Routing Exchange Exposure 465 Routing exchanges include both routing information as well as 466 information associated with the establishment and maintenance of 467 neighbor state information. 469 The exposure of routing information exchanged will allow unauthorized 470 sources to gain access to the content of the exchanges between 471 communicating nodes. The exposure of neighbor state information will 472 allow unauthorized sources to gain knowledge of communication links 473 between routing nodes that are necessary to maintain routing 474 information exchanges. 476 The forms of attack that allow unauthorized access or exposure of 477 routing exchange information, as reported in the literature, include 479 o Deliberate exposure; 481 o Sniffing; 483 o Traffic analysis. 485 4.1.2. Routing Information (Routes and Network Topology) Exposure 487 Routes and neighbor topology information are the products of the 488 routing process that are stored within the node device databases. 490 The exposure of this information will allow unauthorized sources to 491 gain direct access to the configuration and connectivity of the 492 network thereby exposing routing to targeted attacks on key nodes or 493 links. Since routes and neighbor topology information is stored 494 within the node device, threats or attacks on the confidentiality of 495 the information will apply to the physical device including specified 496 and unspecified internal and external interfaces. 498 The forms of attack that allow unauthorized access or exposure of the 499 routing information (other than occurring through explicit node 500 exchanges) will include 502 o Physical device compromise; 504 o Remote device access attacks (including those occurring through 505 remote network management or software/field upgrade interfaces). 507 More detailed descriptions of the exposure attacks on routing 508 exchange and information will be given in Section 5 together with the 509 corresponding countermeasures. 511 4.2. Threats and Attacks on Integrity 513 The assessment in Section 3.2 indicates that information and identity 514 assets are exposed to integrity threats from all points of access. 516 4.2.1. Routing Information Manipulation 518 Manipulation of routing information will allow unauthorized sources 519 to influence the operation and convergence of the routing protocols 520 and ultimately impact the forwarding decisions made in the network. 521 Manipulation of neighbor state (topology) information will allow 522 unauthorized sources to influence the nodes with which routing 523 information is exchanged and updated. The consequence of 524 manipulating routing exchanges can thus lead to sub-optimality and 525 fragmentation or partitioning of the network by restricting the 526 universe of routers with which associations can be established and 527 maintained. 529 The forms of attack that allow manipulation of routing information 530 include 532 o Falsification, including overclaiming and misclaiming; 534 o Routing information replay; 536 o Physical device compromise. 538 4.2.2. Node Identity Misappropriation 540 Falsification or misappropriation of node identity between routing 541 participants opens the door for other attacks; it can also cause 542 incorrect routing relationships to form and/or topologies to emerge. 543 Routing attacks may also be mounted through less sophisticated node 544 identity misappropriation in which the valid information broadcast or 545 exchanged by a node is replayed without modification. The receipt of 546 seemingly valid information that is however no longer current can 547 result in routing disruption, and instability (including failure to 548 converge). Without measures to authenticate the routing participants 549 and to ensure the freshness and validity of the received information 550 the protocol operation can be compromised. The forms of attack that 551 misuse node identity include 553 o Identity (including Sybil) attacks; 555 o Routing information replay. 557 4.3. Threats and Attacks on Availability 559 The assessment in Section 3.2 indicates that the process and 560 resources assets are exposed to availability threats; attacks of this 561 category may exploit directly or indirectly information exchange or 562 forwarding. 564 4.3.1. Routing Exchange Interference or Disruption 566 Interference or disruption of routing information exchanges will 567 allow unauthorized sources to influence the operation and convergence 568 of the routing protocols by impeding the regularity of routing 569 information exchange. 571 The forms of attack that allow interference or disruption of routing 572 exchange include 574 o Routing information replay; 576 o HELLO flood attacks and ACK spoofing; 578 o Overload attacks. 580 4.3.2. Network Traffic Forwarding Disruption 582 The disruption of the network traffic forwarding capability of the 583 network will undermine the central function of network routers and 584 the ability to handle user traffic. This threat and the associated 585 attacks affect the availability of the network because of the 586 potential to impair the primary capability of the network. 588 The forms of attack that allows disruption of network traffic 589 forwarding include 591 o Selective forwarding attacks; 592 o Sinkhole attacks; 594 o Wormhole attacks. 596 4.3.3. Communications Resource Disruption 598 Attacks mounted against the communication channel resource assets 599 needed by the routing protocol can be used as a means of disrupting 600 its operation. However, while various forms of Denial of Service 601 (DoS) attacks on the underlying transport subsystem will affect 602 routing protocol exchanges and operation (for example physical layer 603 RF jamming in a wireless network or link layer attacks), these 604 attacks cannot be countered by the routing protocol. As such, the 605 threats to the underlying transport network that supports routing is 606 considered beyond the scope of the current document. Nonetheless, 607 attacks on the subsystem will affect routing operation and so must be 608 directly addressed within the underlying subsystem and its 609 implemented protocol layers. 611 4.3.4. Node Resource Exhaustion 613 A potential security threat to routing can arise from attempts to 614 exhaust the node resource asset by initiating exchanges that can lead 615 to the undue utilization of exhaustion of processing, memory or 616 energy resources. The establishment and maintenance of routing 617 neighbors opens the routing process to engagement and potential 618 acceptance of multiple neighboring peers. Association information 619 must be stored for each peer entity and for the wireless network 620 operation provisions made to periodically update and reassess the 621 associations. An introduced proliferation of apparent routing peers 622 can therefore have a negative impact on node resources. 624 Node resources may also be unduly consumed by the attackers 625 attempting uncontrolled topology peering or routing exchanges, 626 routing replays, or the generating of other data traffic floods. 627 Beyond the disruption of communications channel resources, these 628 threats may be able to exhaust node resources only where the 629 engagements are able to proceed with the peer routing entities. 630 Routing operation and network forwarding functions can thus be 631 adversely impacted by node resources exhaustion that stems from 632 attacks that include 634 o Identity (including Sybil) attacks; 636 o Routing information replay attacks; 638 o HELLO flood attacks and ACK spoofing; 639 o Overload attacks. 641 5. Countermeasures 643 By recognizing the characteristics of LLNs that may impact routing 644 and identifying potential countermeasures, this framework provides 645 the basis for developing capabilities within ROLL protocols to deter 646 the identified attacks and mitigate the threats. The following 647 subsections consider such countermeasures by grouping the attacks 648 according to the classification of the CIA model so that associations 649 with the necessary security services are more readily visible. 651 5.1. Confidentiality Attack Countermeasures 653 Attacks on confidentiality may be mounted at the level of the routing 654 information assets, at the points of access associated with routing 655 exchanges between nodes, or through device interface access. To gain 656 access to routing/topology information, the attacker may rely on a 657 compromised node that deliberately exposes the information during the 658 routing exchange process, may rely on passive sniffing or analysis of 659 routing traffic, or may attempt access through a component or device 660 interface of a tampered routing node. 662 5.1.1. Countering Deliberate Exposure Attacks 664 A deliberate exposure attack is one in which an entity that is party 665 to the routing process or topology exchange allows the routing/ 666 topology information or generated route information to be exposed to 667 an unauthorized entity during the exchange. 669 A prerequisite to countering this type of confidentiality attacks 670 associated with the routing/topology exchange is to ensure that the 671 communicating nodes are authenticated prior to data encryption 672 applied in the routing exchange. Authentication ensures that the 673 nodes are who they claim to be even though it does not provide an 674 indication of whether the node has been compromised. 676 To prevent deliberate exposure, the process that communicating nodes 677 use for establishing communication session keys must be symmetric at 678 each node so that neither node can independently weaken the 679 confidentiality of the exchange without the knowledge of its 680 communicating peer. A deliberate exposure attack will therefore 681 require more overt and independent action on the part of the 682 offending node. 684 Note that the same measures which apply to securing routing/topology 685 exchanges between operational nodes must also extend to field tools 686 and other devices used in a deployed network where such devices can 687 be configured to participate in routing exchanges. 689 5.1.2. Countering Sniffing Attacks 691 A sniffing attack seeks to breach routing confidentiality through 692 passive, direct analysis and processing of the information exchanges 693 between nodes. A sniffing attack in an LLN that is not based on a 694 physical device compromise will rely on the attacker attempting to 695 directly derive information from the over-the-air routing/topology 696 communication exchange (neighbor discovery exchanges may of necessity 697 be conducted in the clear thus limiting the extent to which the 698 information can be kept confidential). 700 Sniffing attacks can be directly countered through the use of data 701 encryption for all routing exchanges. Only when a validated and 702 authenticated node association is completed will routing exchange be 703 allowed to proceed using established session confidentiality keys and 704 an agreed confidentiality algorithm. The level of security applied 705 in providing confidentiality will determine the minimum requirement 706 for an attacker mounting this passive security attack. Because of 707 the resource constraints of LLN devices, symmetric (private) key 708 session security will provide the best tradeoff in terms of node and 709 channel resource overhead and the level of security achieved. This 710 will of course not preclude the use of asymmetric (public) key 711 encryption during the session key establishment phase. 713 As with the key establishment process, data encryption must include 714 an authentication prerequisite to ensure that each node is 715 implementing a level of security that prevents deliberate or 716 inadvertent exposure. The authenticated key establishment will 717 ensure that confidentiality is not compromised by providing the 718 information to an unauthorized entity (see also [Huang2003]). 720 Based on the current state of the art, a minimum 128-bit key length 721 should be applied where robust confidentiality is demanded for 722 routing protection. This session key shall be applied in conjunction 723 with an encryption algorithm that has been publicly vetted and where 724 applicable approved for the level of security desired. Algorithms 725 such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted 726 by the 3GPP 3rd generation wireless mobile consortium) are examples 727 of symmetric-key algorithms capable of ensuring robust 728 confidentiality for routing exchanges. The key length, algorithm and 729 mode of operation will be selected as part of the overall security 730 tradeoff that also achieves a balance with the level of 731 confidentiality afforded by the physical device in protecting the 732 routing assets (see Section 5.1.4 below). 734 As with any encryption algorithm, the use of ciphering 735 synchronization parameters and limitations to the usage duration of 736 established keys should be part of the security specification to 737 reduce the potential for brute force analysis. 739 5.1.3. Countering Traffic Analysis 741 Traffic analysis provides an indirect means of subverting 742 confidentiality and gaining access to routing information by allowing 743 an attacker to indirectly map the connectivity or flow patterns 744 (including link-load) of the network from which other attacks can be 745 mounted. The traffic analysis attack on a LLN may be passive and 746 relying on the ability to read the immutable source/destination 747 routing information that must remain unencrypted to permit network 748 routing. Alternatively, attacks can be active through the injection 749 of unauthorized discovery traffic into the network. By implementing 750 authentication measures between communicating nodes, active traffic 751 analysis attacks can be prevented within the LLN thereby reducing 752 confidentiality vulnerabilities to those associated with passive 753 analysis. 755 One way in which passive traffic analysis attacks can be muted is 756 through the support of load balancing that allows traffic to a given 757 destination to be sent along diverse routing paths. Where the 758 routing protocol supports load balancing along multiple links at each 759 node, the number of routing permutations in a wide area network 760 surges thus increasing the cost of traffic analysis. Network 761 analysis through this passive attack will require a wider array of 762 analysis points and additional processing on the part of the 763 attacker. In LLNs, the diverse radio connectivity and dynamic links 764 (including potential frequency hopping) will help to further mitigate 765 traffic analysis attacks when load balancing is implemented. 767 The only means of fully countering a traffic analysis attack is 768 through the use of tunneling (encapsulation) where encryption is 769 applied across the entirety of the original packet source/destination 770 addresses. With tunneling there is a further requirement that the 771 encapsulating intermediate nodes apply an additional layer of routing 772 so that traffic arrives at the destination through dynamic routes. 773 For LLNs, memory and processing constraints as well as the 774 limitations of the communication channel will preclude both the 775 additional routing traffic overhead and the node implementation 776 required for tunneling countermeasures to traffic analysis. 778 5.1.4. Countering Physical Device Compromise 780 Given the distributed nature of LLNs, confidentiality of routing 781 assets and points of access will rely heavily on the security of the 782 routing devices. One means of precluding attacks on the physical 783 device is to prevent physical access to the node through other 784 external security means. However, given the environment in which 785 LLNs operate, preventing unauthorized access to the physical device 786 cannot be assured. Countermeasures must therefore be employed at the 787 device and component level so that routing/topology or neighbor 788 information and stored route information cannot be accessed even if 789 physical access to the node is obtained. 791 With the physical device in the possession of an attacker, 792 unauthorized information access can be attempted by probing internal 793 interfaces or device components. Device security must therefore move 794 to preventing the reading of device processor code or memory 795 locations without the appropriate security keys and in preventing the 796 access to any information exchanges occurring between individual 797 components. Information access will then be restricted to external 798 interfaces in which confidentiality, integrity and authentication 799 measures can be applied. 801 To prevent component information access, deployed routing devices 802 must ensure that their implementation avoids address or data buses 803 being connected to external general purpose input/output (GPIO) pins. 804 Beyond this measure, an important component interface to be protected 805 against attack is the Joint Test Action Group (JTAG) interface used 806 for component and populated circuit board testing after manufacture. 807 To provide security on the routing devices, components should be 808 employed that allow fuses on the JTAG interfaces to be blown to 809 disable access. This will raise the bar on unauthorized component 810 information access within a captured device. 812 At the device level a key component information exchange is between 813 the microprocessor and it associated external memory. While 814 encryption can be implemented to secure data bus exchanges, the use 815 of integrated physical packaging which avoids inter-component 816 exchanges (other than secure external device exchanges) will increase 817 routing security against a physical device interface attack. With an 818 integrated package and disabled internal component interfaces, the 819 level of physical device security can be controlled by managing the 820 degree to which the device packaging is protected against expert 821 physical decomposition and analysis. 823 The device package should be hardened such that attempts to remove 824 the integrated components will result in damage to access interfaces, 825 ports or pins that prevent retrieval of code or stored information. 826 The degree of VLSI or PCB package security through manufacture can be 827 selected as a tradeoff or desired security consistent with the level 828 of security achieved by measures applied for other routing assets and 829 points of access. With package hardening and restricted component 830 access countermeasures, the security level will be raised to that 831 provided by measures employed at the external communications 832 interfaces. 834 Another area of node interface vulnerability is that associated with 835 interfaces provided for remote software or firmware upgrades. This 836 may impact both routing information and routing/topology exchange 837 security where it leads to unauthorized upgrade or change to the 838 routing protocol running on a given node as this type of attack can 839 allow for the execution of compromised or intentionally malicious 840 routing code on multiple nodes. Countermeasures to this device 841 interface confidentiality attack needs to be addressed in the larger 842 context of node remote access security. This will ensure not only 843 the authenticity of the provided code (including routing protocol) 844 but that the process is initiated by an authorized (authenticated) 845 entity. 847 The above identified countermeasures against attacks on routing 848 information confidentiality through internal device interface 849 compromise must be part of the larger LLN system security as they 850 cannot be addressed within the routing protocol itself. Similarly, 851 the use of field tools or other devices that allow explicit access to 852 node information must implement security mechanisms to ensure that 853 routing information can be protected against unauthorized access. 854 These protections will also be external to the routing protocol and 855 hence not part of ROLL. 857 5.1.5. Countering Remote Device Access Attacks 859 Where LLN nodes are deployed in the field, measures are introduced to 860 allow for remote retrieval of routing data and for software or field 861 upgrades. These paths create the potential for a device to be 862 remotely accessed across the network or through a provided field 863 tool. In the case of network management a node can be directly 864 requested to provide routing tables and neighbor information. 866 To ensure confidentiality of the node routing information against 867 attacks through remote access, any device local or remote requesting 868 routing information must be authenticated to ensure authorized 869 access. Since remote access is not invoked as part of a routing 870 protocol security of routing information stored on the node against 871 remote access will not be addressable as part of the routing 872 protocol. 874 5.2. Integrity Attack Countermeasures 876 Integrity attack countermeasures address routing information 877 manipulation, as well as node identity and routing information 878 misuse. Manipulation can occur in the form of falsification attack 879 and physical compromise. To be effective, the following development 880 considers the two aspects of falsification, namely, the tampering 881 actions and the overclaiming and misclaiming content. The countering 882 of physical compromise was considered in the previous section and is 883 not repeated here. With regard to misuse, there are two types of 884 attacks to be deterred, identity attacks and replay attacks. 886 5.2.1. Countering Tampering Attacks 888 Tampering may occur in the form of altering the message being 889 transferred or the data stored. Therefore, it is necessary to ensure 890 that only authorized nodes can change the portion of the information 891 that is allowed to be mutable, while the integrity of the rest of the 892 information is protected, e.g., through well-studied cryptographic 893 mechanisms. 895 Tampering may also occur in the form of insertion or deletion of 896 messages during protocol changes. Therefore, the protocol needs to 897 ensure the integrity of the sequence of the exchange sequence. 899 The countermeasure to tampering needs to 901 o implement access control on storage; 903 o provide data integrity service to transferred messages and stored 904 data; 906 o include sequence number under integrity protection. 908 5.2.2. Countering Overclaiming and Misclaiming Attacks 910 Both overclaiming and misclaiming aim to introduce false routes or 911 topology that would not be generated by the network otherwise, while 912 there is not necessarily tampering. The requisite for a counter is 913 the capability to determine unreasonable routes or topology. 915 The counter to overclaiming and misclaiming may employ 917 o comparison with historical routing/topology data; 919 o designs which restrict realizable network topologies. 921 5.2.3. Countering Identity (including Sybil) Attacks 923 Identity attacks, sometimes simply called spoofing, seek to gain or 924 damage assets whose access is controlled through identity. In 925 routing, an identity attacker can illegitimately participate in 926 routing exchanges, distribute false routing information, or cause an 927 invalid outcome of a routing process. 929 A perpetrator of Sybil attacks assumes multiple identities. The 930 result is not only an amplification of the damage to routing, but 931 extension to new areas, e.g., where geographic distribution is 932 explicit or implicit an asset to an application running on the LLN. 934 The counter of identity attacks need to ensure the authenticity and 935 liveness of the parties of a message exchange; the measure may use 936 shared key or public key based authentication scheme. On the one 937 hand, the large-scale nature of the LLNs makes the network-wide 938 shared key scheme undesirable from a security perspective; on the 939 other hand, public-key based approaches generally require more 940 computational resources. Each system will need to make trade-off 941 decisions based on its security requirements. 943 5.2.4. Countering Routing Information Replay Attacks 945 In routing, message replay can result in false topology and/or 946 routes. The counter of replay attacks need to ensure the freshness 947 of the message. On the one hand, there are a number of mechanisms 948 commonly used for countering replay. On the other hand, the choice 949 should take into account how a particular mechanism is made available 950 in a LLN. For example, many LLNs have a central source of time and 951 have it distributed by relaying, such that secured time distribution 952 becomes a prerequisite of using timestamping to counter replay. 954 5.3. Availability Attack Countermeasures 956 As alluded to before, availability requires that routing information 957 exchanges and forwarding mechanisms be available when needed so as to 958 guarantee a proper functioning of the network. This may, e.g., 959 include the correct operation of routing information and neighbor 960 state information exchanges, among others. We will highlight the key 961 features of the security threats along with typical countermeasures 962 to prevent or at least mitigate them. We will also note that an 963 availability attack may be facilitated by an identity attack as well 964 as a replay attack, as was addressed in Section 5.2.3 and 965 Section 5.2.4, respectively. 967 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 969 HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing 970 attacks are different but highly related forms of attacking a LLN. 971 They essentially lead nodes to believe that suitable routes are 972 available even though they are not and hence constitute a serious 973 availability attack. 975 The origin of facilitating a HELLO flood attack lies in the fact that 976 many wireless routing protocols require nodes to send HELLO packets 977 either upon joining or in regular intervals so as to announce or 978 confirm their existence to the network. Those nodes that receive the 979 HELLO packet assume that they are within radio range of the 980 transmitter by means of a bidirectional communication link. 982 With this in mind, a malicious node can send or replay HELLO packets 983 using a higher transmission power. That creates the false illusion 984 of being a neighbor to an increased number of nodes in the network, 985 thereby effectively increasing its unidirectional neighborhood 986 cardinality. The high quality of the falsely advertised link may 987 coerce nodes to route data via the malicious node. However, those 988 affected nodes, for which the malicious node is out of radio range, 989 never succeed in their delivery and the packets are effectively 990 dropped. The symptoms are hence similar to those of a sinkhole, 991 wormhole and selective forwarding attack. 993 A malicious HELLO flood attack clearly distorts the network topology. 994 It thus affects protocols building and maintaining the network 995 topology as well as routing protocols as such, since the attack is 996 primarily targeted on protocols that require sharing of information 997 for topology maintenance or flow control. 999 To counter HELLO flood attacks, several mutually non-exclusive 1000 methods are feasible: 1002 o restricting neighborhood cardinality; 1004 o facilitating multipath routing; 1006 o verifying bidirectionality. 1008 Restricting the neighborhood cardinality prevents malicious nodes 1009 from having an extended set of neighbors beyond some tolerated 1010 threshold and thereby preventing topologies to be built where 1011 malicious nodes have an extended neighborhood set. Furthermore, as 1012 shown in [I-D.suhopark-hello-wsn], if the routing protocol supports 1013 multiple paths from a sensing node towards several gateways then 1014 HELLO flood attacks can also be diminished; however, the energy- 1015 efficiency of such approach is clearly sub-optimal. Finally, 1016 verifying that the link is truly bidirectional by means of, e.g., an 1017 ACK handshake and appropriate security measures ensures that a 1018 communication link is only established if not only the affected node 1019 is within range of the malicious node but also vice versa. Whilst 1020 this does not really eliminate the problem of HELLO flooding, it 1021 greatly reduces the number of affected nodes and the probability of 1022 such an attack succeeding. 1024 As for the latter, the adversary may spoof the ACK messages to 1025 convince the affected node that the link is truly bidirectional and 1026 thereupon drop, tunnel or selectively forward messages. Such ACK 1027 spoofing attack is possible if the malicious node has a receiver 1028 which is significantly more sensitive than that of a normal node, 1029 thereby effectively extending its range. Since an ACK spoofing 1030 attack facilitates a HELLO flood attack, similar countermeasure are 1031 applicable here. Viable counter and security measures for both 1032 attacks have been exposed in [I-D.suhopark-hello-wsn]. 1034 5.3.2. Countering Overload Attacks 1036 Overload attacks are a form of DoS attack in that a malicious node 1037 overloads the network with irrelevant traffic, thereby draining the 1038 nodes' energy budget quicker. It thus significantly shortens the 1039 network lifetime and hence constitutes another serious availability 1040 attack. 1042 With energy being one of the most precious assets of LLNs, targeting 1043 its availability is a fairly obvious attack. Another way of 1044 depleting the energy of a LLN node is to have the malicious node 1045 overload the network with irrelevant traffic. This impacts 1046 availability since certain routes get congested which 1048 o renders them useless for affected nodes and data can hence not be 1049 delivered; 1051 o makes routes longer as shortest path algorithms work with the 1052 congested network; 1054 o depletes nodes quicker and thus shortens the network's 1055 availability at large. 1057 Overload attacks can be countered by deploying a series of mutually 1058 non-exclusive security measures: 1060 o introduce quotas on the traffic rate each node is allowed to send; 1062 o isolate nodes which send traffic above a certain threshold; 1064 o allow only trusted data to be received and forwarded. 1066 As for the first one, a simple approach to minimize the harmful 1067 impact of an overload attack is to introduce traffic quotas. This 1068 prevents a malicious node from injecting a large amount of traffic 1069 into the network, even though it does not prevent said node from 1070 injecting irrelevant traffic at all. Another method is to isolate 1071 nodes from the network once it has been detected that more traffic is 1072 injected into the network than allowed by a prior set or dynamically 1073 adjusted threshold. Finally, if communication is sufficiently 1074 secured, only trusted nodes can receive and forward traffic which 1075 also lowers the risk of an overload attack. 1077 5.3.3. Countering Selective Forwarding Attacks 1079 Selective forwarding attacks are another form of DoS attack which 1080 impacts the routing path availability. 1082 An insider malicious node basically blends neatly in with the network 1083 but then may decide to forward and/or manipulate certain packets. If 1084 all packets are dropped, then this attacker is also often referred to 1085 as a "black hole". Such a form of attack is particularly dangerous 1086 if coupled with sinkhole attacks since inherently a large amount of 1087 traffic is attracted to the malicious node and thereby causing 1088 significant damage. An outside malicious node would selectively jam 1089 overheard data flows, where the thus caused collisions incur 1090 selective forwarding. 1092 Selective Forwarding attacks can be countered by deploying a series 1093 of mutually non-exclusive security measures: 1095 o multipath routing of the same message over disjoint paths; 1097 o dynamically select the next hop from a set of candidates. 1099 The first measure basically guarantees that if a message gets lost on 1100 a particular routing path due to a malicious selective forwarding 1101 attack, there will be another route which successfully delivers the 1102 data. Such method is inherently suboptimal from an energy 1103 consumption point of view. The second method basically involves a 1104 constantly changing routing topology in that next-hop routers are 1105 chosen from a dynamic set in the hope that the number of malicious 1106 nodes in this set is negligible. 1108 5.3.4. Countering Sinkhole Attacks 1110 In sinkhole attacks, the malicious node manages to attract a lot of 1111 traffic mainly by advertising the availability of high-quality links 1112 even though there are none. It hence constitutes a serious attack on 1113 availability. 1115 The malicious node creates a sinkhole by attracting a large amount 1116 of, if not all, traffic from surrounding neighbors by advertising in 1117 and outwards links of superior quality. Affected nodes hence eagerly 1118 route their traffic via the malicious node which, if coupled with 1119 other attacks such as selective forwarding, may lead to serious 1120 availability and security breaches. Such an attack can only be 1121 executed by an inside malicious node and is generally very difficult 1122 to detect. An ongoing attack has a profound impact on the network 1123 topology and essentially becomes a problem of flow control. 1125 Sinkhole attacks can be countered by deploying a series of mutually 1126 non-exclusive security measures: 1128 o use geographical insights for flow control; 1130 o isolate nodes which receive traffic above a certain threshold; 1132 o dynamically pick up next hop from set of candidates; 1134 o allow only trusted data to be received and forwarded. 1136 Whilst most of these countermeasures have been discussed before, the 1137 use of geographical information deserves further attention. 1138 Essentially, if geographic positions of nodes are available, then the 1139 network can assure that data is actually routed towards the sink(s) 1140 and not elsewhere. On the other hand, geographic position is a 1141 sensitive information that may have security and/or privacy 1142 consequences. 1144 5.3.5. Countering Wormhole Attacks 1146 In wormhole attacks at least two malicious nodes shortcut or divert 1147 the usual routing path by means of a low-latency out-of-band channel. 1148 This changes the availability of certain routing paths and hence 1149 constitutes a serious security breach. 1151 Essentially, two malicious insider nodes use another, more powerful, 1152 radio to communicate with each other and thereby distort the would- 1153 be-agreed routing path. This distortion could involve shortcutting 1154 and hence paralyzing a large part of the network; it could also 1155 involve tunneling the information to another region of the network 1156 where there are, e.g., more malicious nodes available to aid the 1157 intrusion or where messages are replayed, etc. In conjunction with 1158 selective forwarding, wormhole attacks can create race conditions 1159 which impact topology maintenance, routing protocols as well as any 1160 security suits built on "time of check" and "time of use". 1162 Wormhole attacks are very difficult to detect in general but can be 1163 mitigated using similar strategies as already outlined above in the 1164 context of sinkhole attacks. 1166 6. ROLL Security Features 1168 The issues discussed in Section 4, together with the countermeasures 1169 described in Section 5, provide the basis for the requirements of the 1170 following ROLL security features. Still, it bears emphasizing that 1171 the target here is a generic ROLL protocol and the normative keywords 1172 are mainly to convey the relative level of urgency of the features 1173 specified. As routing is one component of a LLN system, the actual 1174 strength of the security services afforded to it should be made to 1175 conform to each system's security policy; how a design may address 1176 the needs of the urban, industrial, home automation, and building 1177 automation application domains is considered in Section 6.5. 1179 6.1. Confidentiality Features 1181 To protect confidentiality, a secured ROLL protocol 1183 o SHOULD provide payload encryption; 1185 o MAY provide tunneling; 1187 o MAY provide load balancing; 1189 o SHOULD provide privacy, e.g., when geographic information is used. 1191 6.2. Integrity Features 1193 To protect integrity, a secured ROLL protocol 1195 o MUST verify the liveliness of both principals of a connection; 1197 o MUST verify message freshness; 1199 o MUST verify message sequence and integrity; 1201 6.3. Availability Features 1203 To protect availability, a secured ROLL protocol 1205 o MAY restrict neighborhood cardinality; 1207 o MAY use multiple paths; 1209 o MAY use multiple destinations; 1211 o MAY choose randomly if multiple paths are available; 1212 o MAY set quotas to limit transmit or receive volume; 1214 o MAY use geographic insights for flow control. 1216 6.4. Additional Related Features 1218 If a LLN employs multicast and/or anycast, it MUST secure these 1219 protocols with the services listed in this sections. Furthermore, 1220 the nodes MUST provide adequate physical tamper resistance to ensure 1221 the integrity of stored routing information. 1223 The functioning of the security services requires keys and 1224 credentials. Therefore, even though not directly a ROLL security 1225 requirement, a LLN must include a process for key and credential 1226 distribution; a LLN is encouraged to have procedures for their 1227 revocation and replacement. 1229 6.5. Consideration on Matching Application Domain Needs 1231 The development so far takes into account collectively the impacts of 1232 the issues gathered from [RFC5548], 1233 [I-D.ietf-roll-indus-routing-reqs], 1234 [I-D.ietf-roll-home-routing-reqs], and 1235 [I-D.ietf-roll-building-routing-reqs]. The following two subsections 1236 first consider from an architectural perspective how the security 1237 design of a ROLL protocol may be made to adapt to the four 1238 application domains, and then examine mechanism and protocol 1239 operations issues. 1241 6.5.1. Architecture 1243 The first challenge for a ROLL protocol security design is to have an 1244 architecture that can adequately address a set of very diversified 1245 needs. It is mainly a consequence of the fact that there are both 1246 common and non-overlapping requirements from the four application 1247 domains, while, conceivably, each individual application will present 1248 yet its own unique constraints. 1250 A ROLL protocol MUST be made flexible with a design which allows the 1251 user to choose the security configurations that match the 1252 application's needs. The construct may be, e.g., a header containing 1253 security material of configurable security primitives in the fashion 1254 of OSPFv2 [RFC2328] or RIPv2 [RFC2453]. On the other hand, it is 1255 more desirable from a LLN device perspective that the ROLL protocol 1256 specifies the necessity of an overall system architecture in which 1257 security facility may be shared by different applications and/or 1258 across layers for efficiency, while security policy and settings can 1259 be consistently made, e.g., RIPng [RFC2080] or the approach presented 1260 in [Messerges2003]. 1262 6.5.2. Mechanisms and Operations 1264 With an architecture allowing different configurations to meet the 1265 application domain needs, the task is then to find suitable 1266 mechanisms. This subsection considers the security properties of a 1267 number of mechanisms found in widely employed routing protocols, as 1268 well as how some of their protocol operations affect security. The 1269 discussion is based on analyses found in the open literature. The 1270 intention is to offer a stepping stone for the security design of a 1271 ROLL protocol, as well as to be useful for preventing oversights, but 1272 not an exhaustive in-depth survey 1274 There has been quite an amount of effort applied to the assessment of 1275 the security of routing protocols, e.g., Section 2 of [Wan2004] and 1276 Section 2 of [Babakhouya2006] consider the security properties of RIP 1277 as well as distance vector protocols in general. There are two 1278 issues worth taking note. 1280 Authentication 1281 The current version of RIP allows two options of 1282 authentication, i.e., clear-text password and cryptographic 1283 authentication, which includes keyed-MD5 [RFC4822]. On the one 1284 hand, transporting clear-text passwords without protection is 1285 ineffective for authentication. On the other hand, the key for 1286 the MD5 operation is in a suffix position only and as such the 1287 key may be vulnerable to cryptanalysis [Kaliski1995]. 1289 Information Aggregation 1290 Distance vector routers periodically exchange route updates 1291 that is the output of a computation on information gathered 1292 locally, making it difficult for the receiver to verify the 1293 correctness or resolve the sources of the information that went 1294 into the updates. 1296 There are also plenty of analyses on link state based protocols, 1297 especially on OSPF, e.g., [Wang1998] and [I-D.ietf-rpsec-ospf-vuln] 1298 are both entirely on this protocol. The following issues about OSPF 1299 are of interest. 1301 The Age Field 1302 The Age field in the Link State Advertisement (LSA) is updated 1303 by each receiver; it is not covered by the integrity protection 1304 mechanism in OSPFv2 and so is exposed to forgery. OSPFv3 1305 [RFC5340] relegates security services to the underlying IPv6's 1306 security mechanisms. 1308 LSA Flooding 1309 LSAs are disseminated through flooding. The router 1310 corresponding to the claimed advertiser of a LSA can either 1311 flush or update to correct inconsistencies. However, this 1312 mechanism may be defeated by a persistent attacker 1313 [I-D.ietf-rpsec-ospf-vuln], is ineffective when the legitimate 1314 owner does not receive the altered LSA, or the claimed 1315 advertiser does not exist. 1317 Hierarchical Routing 1318 Partitioning of the autonomous system into areas facilitates 1319 scaling and also helps the containment of incorrect information 1320 to within an area. On the other hand, routing information from 1321 autonomous system border routers are flooded throughout the 1322 autonomous system and thus have significant security 1323 consequences. 1325 The foregoing discussion has been based on widely employed routing 1326 protocols for the many studies they received can contribute to 1327 informed design decisions. In addition, the attention was limited to 1328 those elements that are more relevant to a potential ROLL protocol 1329 design. 1331 7. IANA Considerations 1333 This memo includes no request to IANA. 1335 8. Security Considerations 1337 The framework presented in this document provides security analysis 1338 and design guidelines with a scope limited to ROLL. The 1339 investigation is at a high-level and not specific to a particular 1340 protocol. Security services, but not mechanisms, are identified as 1341 requirements for securing ROLL. 1343 9. Acknowledgments 1345 10. References 1347 10.1. Normative References 1349 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1350 January 1997. 1352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1353 Requirement Levels", BCP 14, RFC 2119, March 1997. 1355 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1357 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1358 November 1998. 1360 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 1361 Authentication", RFC 4822, February 2007. 1363 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1364 for IPv6", RFC 5340, July 2008. 1366 10.2. Informative References 1368 [Babakhouya2006] 1369 Babakhouya, A., Challal, Y., Bouabdallah, M., and S. 1370 Gharout, "SDV: A New Approach to Secure Distance Vector 1371 Routing Protocols", IEEE Securecomm and 1372 Workshops, Baltimore, MD, USA, pp. 1-10, Aug. 28-Sept. 1373 1 2006. 1375 [Huang2003] 1376 Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. 1377 Zhang, "Fast Authenticated Key Establishment Protocols for 1378 Self-Organizing Sensor Networks", in Proceedings of the 1379 2nd ACM International Conference on Wireless Sensor 1380 Networks and Applications, San Diego, CA, USA, pp. 141- 1381 150, Sept. 19 2003. 1383 [I-D.ietf-roll-building-routing-reqs] 1384 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 1385 "Building Automation Routing Requirements in Low Power and 1386 Lossy Networks", draft-ietf-roll-building-routing-reqs-07 1387 (work in progress), September 2009. 1389 [I-D.ietf-roll-home-routing-reqs] 1390 Brandt, A., Buron, J., and G. Porcu, "Home Automation 1391 Routing Requirements in Low Power and Lossy Networks", 1392 draft-ietf-roll-home-routing-reqs-08 (work in progress), 1393 September 2009. 1395 [I-D.ietf-roll-indus-routing-reqs] 1396 Networks, D., Thubert, P., Dwars, S., and T. Phinney, 1397 "Industrial Routing Requirements in Low Power and Lossy 1398 Networks", draft-ietf-roll-indus-routing-reqs-06 (work in 1399 progress), June 2009. 1401 [I-D.ietf-roll-terminology] 1402 Vasseur, J., "Terminology in Low power And Lossy 1403 Networks", draft-ietf-roll-terminology-01 (work in 1404 progress), May 2009. 1406 [I-D.ietf-rpsec-ospf-vuln] 1407 Jones, E. and O. Moigne, "OSPF Security Vulnerabilities 1408 Analysis", draft-ietf-rpsec-ospf-vuln-02 (work in 1409 progress), June 2006. 1411 [I-D.suhopark-hello-wsn] 1412 Park, S., "Routing Security in Sensor Network: HELLO Flood 1413 Attack and Defense", draft-suhopark-hello-wsn-00 (work in 1414 progress), December 2005. 1416 [Kaliski1995] 1417 Kaliski, B. and M. Robshaw, "Message Authentication with 1418 MD5", RSA Labs' CryptoBytes, 1(1):5-8, 1995. 1420 [Karlof2003] 1421 Karlof, C. and D. Wagner, "Secure routing in wireless 1422 sensor networks: attacks and countermeasures", Elsevier 1423 AdHoc Networks Journal, Special Issue on Sensor Network 1424 Applications and Protocols, 1(2):293-315, September 2003. 1426 [Messerges2003] 1427 Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, 1428 R., and E. Callaway, "Low-Power Security for Wireless 1429 Sensor Networks", in Proceedings of the 1st ACM Workshop 1430 on Security of Ad Hoc and Sensor Networks, Fairfax, VA, 1431 USA, pp. 1-11, Oct. 31 2003. 1433 [Myagmar2005] 1434 Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as 1435 a Basis for Security Requirements", in Proceedings of the 1436 Symposium on Requirements Engineering for Information 1437 Security (SREIS'05), Paris, France, pp. 94-102, Aug 1438 29, 2005. 1440 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1441 Routing Protocols", RFC 4593, October 2006. 1443 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1444 RFC 4949, August 2007. 1446 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1447 "Routing Requirements for Urban Low-Power and Lossy 1448 Networks", RFC 5548, May 2009. 1450 [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A 1451 Secure Distance Vector Routing Protocol", in Proceedings 1452 of the 2nd International Conference on Applied 1453 Cryptography and Network Security, Yellow Mountain, China, 1454 pp. 103-119, Jun. 8-11 2004. 1456 [Wang1998] 1457 Wang, F. and SF. Wu, "On the Vulnerabilities and 1458 Protection of OSPF Routing Protocol", in Proceedings of 1459 the 7th International Conference on Computer 1460 Communications and Networks, Lafayette, LA, USA, pp. 148- 1461 152, Oct. 12-15 1998. 1463 Authors' Addresses 1465 Tzeta Tsao (editor) 1466 Eka Systems 1467 20201 Century Blvd. Suite 250 1468 Germantown, Maryland 20874 1469 USA 1471 Email: tzeta.tsao@ekasystems.com 1473 Roger K. Alexander (editor) 1474 Eka Systems 1475 20201 Century Blvd. Suite 250 1476 Germantown, Maryland 20874 1477 USA 1479 Email: roger.alexander@ekasystems.com 1481 Mischa Dohler (editor) 1482 CTTC 1483 Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 1484 Castelldefels, Barcelona 08860 1485 Spain 1487 Email: mischa.dohler@cttc.es 1488 Vanesa Daza (editor) 1489 Universitat Pompeu Fabra 1490 P/ Circumval.lacio 8, Oficina 308 1491 Barcelona 08003 1492 Spain 1494 Email: vanesa.daza@upf.edu 1496 Angel Lozano (editor) 1497 Universitat Pompeu Fabra 1498 P/ Circumval.lacio 8, Oficina 309 1499 Barcelona 08003 1500 Spain 1502 Email: angel.lozano@upf.edu