idnits 2.17.00 (12 Aug 2021) /tmp/idnits16838/draft-tsao-roll-security-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 8, 2010) is 4457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-roll-building-routing-reqs has been published as RFC 5867 == Outdated reference: draft-ietf-roll-home-routing-reqs has been published as RFC 5826 == Outdated reference: draft-ietf-roll-rpl has been published as RFC 6550 == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 Summary: 1 error (**), 0 flaws (~~), 5 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: September 9, 2010 M. Dohler, Ed. 6 CTTC 7 V. Daza, Ed. 8 A. Lozano, Ed. 9 Universitat Pompeu Fabra 10 March 8, 2010 12 A Security Framework for Routing over Low Power and Lossy Networks 13 draft-tsao-roll-security-framework-02 15 Abstract 17 This document presents a security framework for routing over low 18 power and lossy networks. The development builds upon previous work 19 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 RPL. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in RFC 32 2119 [RFC2119]. 34 Status of this Memo 36 This Internet-Draft is submitted to IETF in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that 41 other groups may also distribute working documents as Internet- 42 Drafts. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt. 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 This Internet-Draft will expire on September 9, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the BSD License. 71 Table of Contents 73 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Considerations on ROLL Security . . . . . . . . . . . . . . . 5 76 3.1. Routing Assets and Points of Access . . . . . . . . . . . 6 77 3.2. The CIA Security Reference Model . . . . . . . . . . . . . 8 78 3.3. Issues Specific to or Amplified in LLNs . . . . . . . . . 9 79 3.4. ROLL Security Objectives . . . . . . . . . . . . . . . . . 11 80 4. Threats and Attacks . . . . . . . . . . . . . . . . . . . . . 12 81 4.1. Threats and Attacks on Confidentiality . . . . . . . . . . 12 82 4.1.1. Routing Exchange Exposure . . . . . . . . . . . . . . 12 83 4.1.2. Routing Information (Routes and Network Topology) 84 Exposure . . . . . . . . . . . . . . . . . . . . . . . 13 85 4.2. Threats and Attacks on Integrity . . . . . . . . . . . . . 13 86 4.2.1. Routing Information Manipulation . . . . . . . . . . . 14 87 4.2.2. Node Identity Misappropriation . . . . . . . . . . . . 14 88 4.3. Threats and Attacks on Availability . . . . . . . . . . . 15 89 4.3.1. Routing Exchange Interference or Disruption . . . . . 15 90 4.3.2. Network Traffic Forwarding Disruption . . . . . . . . 15 91 4.3.3. Communications Resource Disruption . . . . . . . . . . 15 92 4.3.4. Node Resource Exhaustion . . . . . . . . . . . . . . . 16 93 5. Countermeasures . . . . . . . . . . . . . . . . . . . . . . . 16 94 5.1. Confidentiality Attack Countermeasures . . . . . . . . . . 17 95 5.1.1. Countering Deliberate Exposure Attacks . . . . . . . . 17 96 5.1.2. Countering Sniffing Attacks . . . . . . . . . . . . . 17 97 5.1.3. Countering Traffic Analysis . . . . . . . . . . . . . 19 98 5.1.4. Countering Physical Device Compromise . . . . . . . . 19 99 5.1.5. Countering Remote Device Access Attacks . . . . . . . 21 100 5.2. Integrity Attack Countermeasures . . . . . . . . . . . . . 21 101 5.2.1. Countering Tampering Attacks . . . . . . . . . . . . . 22 102 5.2.2. Countering Overclaiming and Misclaiming Attacks . . . 22 103 5.2.3. Countering Identity (including Sybil) Attacks . . . . 22 104 5.2.4. Countering Routing Information Replay Attacks . . . . 23 105 5.2.5. Countering Byzantine Routing Information Attacks . . . 23 106 5.3. Availability Attack Countermeasures . . . . . . . . . . . 24 107 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing 108 Attacks . . . . . . . . . . . . . . . . . . . . . . . 24 109 5.3.2. Countering Overload Attacks . . . . . . . . . . . . . 26 110 5.3.3. Countering Selective Forwarding Attacks . . . . . . . 27 111 5.3.4. Countering Sinkhole Attacks . . . . . . . . . . . . . 27 112 5.3.5. Countering Wormhole Attacks . . . . . . . . . . . . . 28 113 6. ROLL Security Features . . . . . . . . . . . . . . . . . . . . 28 114 6.1. Confidentiality Features . . . . . . . . . . . . . . . . . 29 115 6.2. Integrity Features . . . . . . . . . . . . . . . . . . . . 30 116 6.3. Availability Features . . . . . . . . . . . . . . . . . . 31 117 6.4. Additional Related Features . . . . . . . . . . . . . . . 31 118 6.5. Consideration on Matching Application Domain Needs . . . . 31 119 6.5.1. Security Architecture . . . . . . . . . . . . . . . . 32 120 6.5.2. Mechanisms and Operations . . . . . . . . . . . . . . 34 121 7. Application of ROLL Security Framework to RPL . . . . . . . . 36 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 124 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 125 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 126 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 127 11.2. Informative References . . . . . . . . . . . . . . . . . . 39 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 130 1. Terminology 132 This document conforms to the terminology defined in 133 [I-D.ietf-roll-terminology]. 135 2. Introduction 137 In recent times, networked wireless devices have found an increasing 138 number of applications in various fields. Yet, for reasons ranging 139 from operational application to economics, these wireless devices are 140 often supplied with minimum physical resources, e.g., limited power 141 reserve, slow speed or low capability computation, or small memory 142 size. As a consequence, the resulting networks are more prone to 143 loss of traffic and other vulnerabilities. The proliferation of 144 these low power and lossy networks (LLNs), however, are drawing 145 efforts to examine and address their potential networking challenges. 147 This document presents a framework for securing routing over low 148 power and lossy networks (ROLL) through an analysis that starts from 149 the routing basics. The objective is two-fold. First, the framework 150 will be used to identify pertinent security issues. Second, it will 151 facilitate both the assessment of a protocol's security threats and 152 the identification of the necessary features for development of 153 secure protocols for ROLL. 155 The approach adopted in this effort proceeds in four steps, to 156 examine ROLL security issues, to analyze threats and attacks, to 157 consider the countermeasures, and then to make recommendations for 158 securing ROLL. The basis is found on identifying the assets and 159 points of access of routing and evaluating their security needs based 160 on the Confidentiality, Integrity, and Availability (CIA) model in 161 the context of LLN. The utility of this framework is demonstrated 162 with an application to RPL [I-D.ietf-roll-rpl]. 164 3. Considerations on ROLL Security 166 This section sets the stage for the development of the framework by 167 applying the systematic approach proposed in [Myagmar2005] to the 168 routing security problem, while also drawing references from other 169 reviews and assessments found in the literature, particularly, 170 [RFC4593] and [Karlof2003]. The subsequent subsections begin with a 171 focus on the elements of a generic routing process that is used to 172 establish routing assets and points of access of the routing 173 functionality. Next, the CIA security model is briefly described. 174 Then, consideration is given to issues specific to or amplified in 175 LLNs. This section concludes with the formulation of a set of 176 security objectives for ROLL. 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_l|<-------------------------------------------+ 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; 262 * communication channel resources (bandwidth); 264 * node resources (computing capacity, memory, and remaining 265 energy); 267 * node identifiers (including node identity and ascribed 268 attributes such as relative or absolute node location). 270 o Points of access include 272 * neighbor discovery; 274 * route/topology exchange; 276 * node physical interfaces (including access to data storage). 278 A focus on the above list of assets and points of access enables a 279 more directed assessment of routing security. Indeed, the intention 280 is to be comprehensive; nonetheless, the discussions to follow on 281 physical related issues are not related to routing protocol design 282 but provided for reference since they do have direct consequences on 283 the security of routing. 285 3.2. The CIA Security Reference Model 287 At the conceptual level, security within an information system in 288 general and applied to ROLL in particular is concerned with the 289 primary issues of confidentiality, integrity, and availability. In 290 the context of ROLL: 292 Confidentiality 293 Confidentiality involves the protection of routing information 294 as well as routing neighbor maintenance exchanges so that only 295 authorized and intended network entities may view or access it. 296 Because of the wireless, and sometimes ad hoc, nature of the 297 network, confidentiality also extends to the neighbor state and 298 database information within the routing device since the 299 deployment of the network creates the potential for 300 unauthorized access to the physical devices themselves. 302 Integrity 303 Integrity, as a security principle, entails the protection of 304 routing information and routing neighbor maintenance exchanges, 305 as well as derived information maintained in the database, from 306 misuse or unauthorized and improper modification. In addition, 307 integrity also requires the authenticity of claimed identity in 308 the origin and destination of a message, access and removal of 309 data, execution of the routing process, and use of computing 310 and energy resources. 312 Availability 313 Availability ensures that routing information exchanges and 314 forwarding services need to be available when they are required 315 for the functioning of the serving network. Availability will 316 apply to maintaining efficient and correct operation of routing 317 and neighbor discovery exchanges (including needed information) 318 and forwarding services so as not to impair or limit the 319 network's central traffic flow function. 321 It is noted that, besides those captured in the CIA model, non- 322 repudiation is a security interest under certain circumstances. With 323 respect to routing, non-repudiation will involve providing some 324 ability to allow traceability or network management review of 325 participants of the routing process including the ability to 326 determine the events and actions leading to a particular routing 327 state. Non-repudiation implies after the fact and thus relies on the 328 logging or other capture of on-going routing exchanges. Given the 329 limited resources of a node and potentially the communication 330 channel, and considering the operating mode associated with LLNs, 331 routing transaction logging or auditing process communication 332 overhead will not be practical; as such, non-repudiation is not 333 further considered as a relevant ROLL security issue. 335 3.3. Issues Specific to or Amplified in LLNs 337 The work [RFC5548] and [RFC5673], as well as two other ongoing 338 efforts, [I-D.ietf-roll-home-routing-reqs] and 339 [I-D.ietf-roll-building-routing-reqs], have identified ROLL specific 340 requirements and constraints for the urban, industrial, home 341 automation, and building automation application domains, 342 respectively. The following is a list of observations and evaluation 343 of their impact on routing security considerations. 345 Limited energy reserve, memory, and processing resources 346 As a consequence of these constraints, there is an even more 347 critical need than usual for a careful trade study on which and 348 what level of security services are to be afforded during the 349 system design process. In addition, the choices of security 350 mechanisms are more stringent. Synchronization of security 351 states with sleepy nodes is yet another issues. 353 Large scale of rolled out network 354 The possibly numerous nodes to be deployed, as well as the 355 general level of expertise of the installers, make manual on- 356 site configuration unlikely. Prolonged rollout and delayed 357 addition of nodes, which may be from old inventory, over the 358 lifetime of the network, also complicate the operations of key 359 management. 361 Autonomous operations 362 Self-forming and self-organizing are commonly prescribed 363 requirements of ROLL. In other words, a ROLL protocol needs to 364 contain elements of ad hoc networking and cannot rely on manual 365 configuration for initialization or local filtering rules. 367 Network topology/ownership changes, partitioning or merging, as 368 well as node replacement, can all contribute to key management 369 issues. 371 Highly directional traffic 372 Some types of LLNs see a high percentage of their total traffic 373 traverse between the nodes and the gateways where the LLNs 374 connect to wired networks. The special routing status of and 375 the greater volume of traffic near the gateways/sinks have 376 routing security consequences. 378 Unattended locations and limited physical security 379 Many applications have the nodes deployed in unattended or 380 remote locations; furthermore, the nodes themselves are often 381 built with minimal physical protection. These constraints 382 lower the barrier of accessing the data or security material 383 stored on the nodes through physical means. 385 Support for mobility 386 On the one hand, only a number of applications require the 387 support of mobile nodes, e.g., a home LLN that includes nodes 388 on wearable health care devices or an industry LLN that 389 includes nodes on cranes and vehicles. On the other hand, if a 390 routing protocol is indeed used in such applications, it will 391 clearly need to have corresponding security mechanisms. 393 Support for multicast and anycast 394 Support for multicast and anycast is called out chiefly for 395 large-scale networks. As these are relatively new routing 396 technologies, there has been an ongoing effort devoted to their 397 security mechanisms, e.g., from the IETF Multicast Security 398 working group. However, inclusion of such mechanisms in a 399 routing protocol, and consequently their security analysis, are 400 still areas not fully developed or their impact entirely 401 understood, whether in a more traditional wired or wireless 402 network, or LLN. 404 The above list considers how a LLN's physical constraints, size, 405 operations, and varieties of application areas may impact security. 406 It is noted here also that LLNs commonly have the majority, if not 407 all, of their nodes equipped to route. One of the consequences is 408 that the distinction between the link and network layers become 409 artificial in some respects. Similarly, the distinction between a 410 host and a router is blurred, especially when the set of applications 411 running on a node is small. The continued evolution of ROLL and its 412 security functionality requirements need close attention. 414 3.4. ROLL Security Objectives 416 This subsection applies the CIA model to the routing assets and 417 access points, taking into account the LLN issues, to develop a set 418 of ROLL security objectives. 420 Since the fundament function of a routing protocol is to build routes 421 for forwarding packets, it is essential to ensure that 423 o routing/topology information is not tampered during transfer and 424 in storage; 426 o routing/topology information is not misappropriated; 428 o routing/topology information is available when needed. 430 In conjunction, it is necessary to be assured of 432 o the authenticity and legitimacy of the participants of the 433 neighbor discovery process; 435 o the routing/topology information received was faithfully generated 436 according to the protocol design. 438 However, when trust cannot be fully vested through authentication of 439 the principals alone, i.e., concerns of insider attack, assurance of 440 the truthfulness and timeliness of the received routing/topology 441 information is necessary. With regard to confidentiality, protecting 442 the routing/topology information from eavesdropping or unauthorized 443 exposure is in itself less pertinent in general to the routing 444 function. 446 One of the main problems of synchronizing security states of sleepy 447 nodes, as listed in the last subsection, lies in difficulties in 448 authentication; these nodes may not have received in time the most 449 recent update of security material. Similarly, the issues of minimal 450 manual configuration, prolonged rollout and delayed addition of 451 nodes, and network topology changes also complicate key management. 452 Hence, ROLL needs to bootstrap the authentication process and allow 453 for flexible expiration scheme of authentication credentials. 455 The vulnerability brought forth by some special-function nodes, e.g., 456 gateways/sinks requires the assurance, particularly, 458 o of the availability of communication channels and node resources; 460 o that the neighbor discovery process operates without undermining 461 routing availability. 463 There are other factors which are not part of a ROLL protocol but 464 directly affecting its function. These factors include weaker 465 barrier of accessing the data or security material stored on the 466 nodes through physical means; therefore, the internal and external 467 interfaces of a node need to be adequate for guarding the integrity, 468 and possibly the confidentiality, of stored information, as well as 469 the integrity of routing and route generation processes. 471 Each individual system's use and environment will dictate how the 472 above objectives are applied, including the choices of security 473 services as well as the strengths of the mechanisms that must be 474 implemented. The next two sections give a closer look at how the 475 ROLL security objectives may be compromised and countered, 476 respectively. 478 4. Threats and Attacks 480 This section outlines general categories of threats under the CIA 481 model and highlights the specific attacks in each of these categories 482 for ROLL. As defined in [RFC4949], a threat is "a potential for 483 violation of security, which exists when there is a circumstance, 484 capability, action, or event that could breach security and cause 485 harm." An attack is "an assault on system security that derives from 486 an intelligent threat, i.e., an intelligent act that is a deliberate 487 attempt (especially in the sense of a method or technique) to evade 488 security services and violate the security policy of a system." 490 The subsequent subsections consider the threats and their realizing 491 attacks that can cause security breaches under the CIA model to the 492 assets identified in Section 3.1. The analysis steps through the 493 security concerns of each routing asset and looks at the attacks that 494 can exploit points of access. The manifestation of the attacks is 495 assumed to be from either inside or outside attackers, whose 496 capabilities may be limited to node-equivalent or more sophisticated 497 computing platforms. 499 4.1. Threats and Attacks on Confidentiality 501 The assessment in Section 3.2 indicates that information assets are 502 exposed to confidentiality threats from all points of access. 504 4.1.1. Routing Exchange Exposure 506 Routing exchanges include both routing information as well as 507 information associated with the establishment and maintenance of 508 neighbor state information. 510 The exposure of routing information exchanged will allow unauthorized 511 sources to gain access to the content of the exchanges between 512 communicating nodes. The exposure of neighbor state information will 513 allow unauthorized sources to gain knowledge of communication links 514 between routing nodes that are necessary to maintain routing 515 information exchanges. 517 The forms of attack that allow unauthorized access or exposure of 518 routing exchange information, as reported in the literature, include 520 o Deliberate exposure; 522 o Sniffing; 524 o Traffic analysis. 526 4.1.2. Routing Information (Routes and Network Topology) Exposure 528 Routes and neighbor topology information are the products of the 529 routing process that are stored within the node device databases. 531 The exposure of this information will allow unauthorized sources to 532 gain direct access to the configuration and connectivity of the 533 network thereby exposing routing to targeted attacks on key nodes or 534 links. Since routes and neighbor topology information is stored 535 within the node device, threats or attacks on the confidentiality of 536 the information will apply to the physical device including specified 537 and unspecified internal and external interfaces. 539 The forms of attack that allow unauthorized access or exposure of the 540 routing information (other than occurring through explicit node 541 exchanges) will include 543 o Physical device compromise; 545 o Remote device access attacks (including those occurring through 546 remote network management or software/field upgrade interfaces). 548 More detailed descriptions of the exposure attacks on routing 549 exchange and information will be given in Section 5 together with the 550 corresponding countermeasures. 552 4.2. Threats and Attacks on Integrity 554 The assessment in Section 3.2 indicates that information and identity 555 assets are exposed to integrity threats from all points of access. 557 4.2.1. Routing Information Manipulation 559 Manipulation of routing information will allow unauthorized sources 560 to influence the operation and convergence of the routing protocols 561 and ultimately impact the forwarding decisions made in the network. 562 Manipulation of neighbor state (topology) information will allow 563 unauthorized sources to influence the nodes with which routing 564 information is exchanged and updated. The consequence of 565 manipulating routing exchanges can thus lead to sub-optimality and 566 fragmentation or partitioning of the network by restricting the 567 universe of routers with which associations can be established and 568 maintained. 570 The forms of attack that allow manipulation to compromise the content 571 and validity of routing information include 573 o Falsification, including overclaiming and misclaiming; 575 o Routing information replay; 577 o Byzantine (internal) attacks that permit corruption of routing 578 information in the node even where the node continues to be a 579 validated entity within the network; 581 o Physical device compromise. 583 4.2.2. Node Identity Misappropriation 585 Falsification or misappropriation of node identity between routing 586 participants opens the door for other attacks; it can also cause 587 incorrect routing relationships to form and/or topologies to emerge. 588 Routing attacks may also be mounted through less sophisticated node 589 identity misappropriation in which the valid information broadcast or 590 exchanged by a node is replayed without modification. The receipt of 591 seemingly valid information that is however no longer current can 592 result in routing disruption, and instability (including failure to 593 converge). Without measures to authenticate the routing participants 594 and to ensure the freshness and validity of the received information 595 the protocol operation can be compromised. The forms of attack that 596 misuse node identity include 598 o Identity (including Sybil) attacks; 600 o Routing information replay. 602 4.3. Threats and Attacks on Availability 604 The assessment in Section 3.2 indicates that the process and 605 resources assets are exposed to availability threats; attacks of this 606 category may exploit directly or indirectly information exchange or 607 forwarding. 609 4.3.1. Routing Exchange Interference or Disruption 611 Interference or disruption of routing information exchanges will 612 allow unauthorized sources to influence the operation and convergence 613 of the routing protocols by impeding the regularity of routing 614 information exchange. 616 The forms of attack that allow interference or disruption of routing 617 exchange include 619 o Routing information replay; 621 o HELLO flood attacks and ACK spoofing; 623 o Overload attacks. 625 4.3.2. Network Traffic Forwarding Disruption 627 The disruption of the network traffic forwarding capability of the 628 network will undermine the central function of network routers and 629 the ability to handle user traffic. This threat and the associated 630 attacks affect the availability of the network because of the 631 potential to impair the primary capability of the network. 633 The forms of attack that allows disruption of network traffic 634 forwarding include 636 o Selective forwarding attacks; 638 o Sinkhole attacks; 640 o Wormhole attacks. 642 4.3.3. Communications Resource Disruption 644 Attacks mounted against the communication channel resource assets 645 needed by the routing protocol can be used as a means of disrupting 646 its operation. However, while various forms of Denial of Service 647 (DoS) attacks on the underlying transport subsystem will affect 648 routing protocol exchanges and operation (for example physical layer 649 RF jamming in a wireless network or link layer attacks), these 650 attacks cannot be countered by the routing protocol. As such, the 651 threats to the underlying transport network that supports routing is 652 considered beyond the scope of the current document. Nonetheless, 653 attacks on the subsystem will affect routing operation and so must be 654 directly addressed within the underlying subsystem and its 655 implemented protocol layers. 657 4.3.4. Node Resource Exhaustion 659 A potential security threat to routing can arise from attempts to 660 exhaust the node resource asset by initiating exchanges that can lead 661 to the undue utilization of exhaustion of processing, memory or 662 energy resources. The establishment and maintenance of routing 663 neighbors opens the routing process to engagement and potential 664 acceptance of multiple neighboring peers. Association information 665 must be stored for each peer entity and for the wireless network 666 operation provisions made to periodically update and reassess the 667 associations. An introduced proliferation of apparent routing peers 668 can therefore have a negative impact on node resources. 670 Node resources may also be unduly consumed by the attackers 671 attempting uncontrolled topology peering or routing exchanges, 672 routing replays, or the generating of other data traffic floods. 673 Beyond the disruption of communications channel resources, these 674 threats may be able to exhaust node resources only where the 675 engagements are able to proceed with the peer routing entities. 676 Routing operation and network forwarding functions can thus be 677 adversely impacted by node resources exhaustion that stems from 678 attacks that include 680 o Identity (including Sybil) attacks; 682 o Routing information replay attacks; 684 o HELLO flood attacks and ACK spoofing; 686 o Overload attacks. 688 5. Countermeasures 690 By recognizing the characteristics of LLNs that may impact routing 691 and identifying potential countermeasures, this framework provides 692 the basis for developing capabilities within ROLL protocols to deter 693 the identified attacks and mitigate the threats. The following 694 subsections consider such countermeasures by grouping the attacks 695 according to the classification of the CIA model so that associations 696 with the necessary security services are more readily visible. 698 However, the considerations here are more systematic than confined to 699 means available only within routing; the next section will then 700 distill and make recommendations appropriate for a secured ROLL 701 protocol. 703 5.1. Confidentiality Attack Countermeasures 705 Attacks on confidentiality may be mounted at the level of the routing 706 information assets, at the points of access associated with routing 707 exchanges between nodes, or through device interface access. To gain 708 access to routing/topology information, the attacker may rely on a 709 compromised node that deliberately exposes the information during the 710 routing exchange process, may rely on passive sniffing or analysis of 711 routing traffic, or may attempt access through a component or device 712 interface of a tampered routing node. 714 5.1.1. Countering Deliberate Exposure Attacks 716 A deliberate exposure attack is one in which an entity that is party 717 to the routing process or topology exchange allows the routing/ 718 topology information or generated route information to be exposed to 719 an unauthorized entity during the exchange. 721 A prerequisite to countering this type of confidentiality attacks 722 associated with the routing/topology exchange is to ensure that the 723 communicating nodes are authenticated prior to data encryption 724 applied in the routing exchange. Authentication ensures that the 725 nodes are who they claim to be even though it does not provide an 726 indication of whether the node has been compromised. 728 To prevent deliberate exposure, the process that communicating nodes 729 use for establishing communication session keys must be symmetric at 730 each node so that neither node can independently weaken the 731 confidentiality of the exchange without the knowledge of its 732 communicating peer. A deliberate exposure attack will therefore 733 require more overt and independent action on the part of the 734 offending node. 736 Note that the same measures which apply to securing routing/topology 737 exchanges between operational nodes must also extend to field tools 738 and other devices used in a deployed network where such devices can 739 be configured to participate in routing exchanges. 741 5.1.2. Countering Sniffing Attacks 743 A sniffing attack seeks to breach routing confidentiality through 744 passive, direct analysis and processing of the information exchanges 745 between nodes. A sniffing attack in an LLN that is not based on a 746 physical device compromise will rely on the attacker attempting to 747 directly derive information from the over-the-air routing/topology 748 communication exchange (neighbor discovery exchanges may of necessity 749 be conducted in the clear thus limiting the extent to which the 750 information can be kept confidential). 752 Sniffing attacks can be directly countered through the use of data 753 encryption for all routing exchanges. Only when a validated and 754 authenticated node association is completed will routing exchange be 755 allowed to proceed using established session confidentiality keys and 756 an agreed confidentiality algorithm. The level of security applied 757 in providing confidentiality will determine the minimum requirement 758 for an attacker mounting this passive security attack. Because of 759 the resource constraints of LLN devices, symmetric (private) key 760 session security will provide the best tradeoff in terms of node and 761 channel resource overhead and the level of security achieved. This 762 will of course not preclude the use of asymmetric (public) key 763 encryption during the session key establishment phase. 765 As with the key establishment process, data encryption must include 766 an authentication prerequisite to ensure that each node is 767 implementing a level of security that prevents deliberate or 768 inadvertent exposure. The authenticated key establishment will 769 ensure that confidentiality is not compromised by providing the 770 information to an unauthorized entity (see also [Huang2003]). 772 Based on the current state of the art, a minimum 128-bit key length 773 should be applied where robust confidentiality is demanded for 774 routing protection. This session key shall be applied in conjunction 775 with an encryption algorithm that has been publicly vetted and where 776 applicable approved for the level of security desired. Algorithms 777 such as AES (adopted by the U.S. government) or Kasumi-Misty (adopted 778 by the 3GPP 3rd generation wireless mobile consortium) are examples 779 of symmetric-key algorithms capable of ensuring robust 780 confidentiality for routing exchanges. The key length, algorithm and 781 mode of operation will be selected as part of the overall security 782 tradeoff that also achieves a balance with the level of 783 confidentiality afforded by the physical device in protecting the 784 routing assets (see Section 5.1.4 below). 786 As with any encryption algorithm, the use of ciphering 787 synchronization parameters and limitations to the usage duration of 788 established keys should be part of the security specification to 789 reduce the potential for brute force analysis. 791 5.1.3. Countering Traffic Analysis 793 Traffic analysis provides an indirect means of subverting 794 confidentiality and gaining access to routing information by allowing 795 an attacker to indirectly map the connectivity or flow patterns 796 (including link-load) of the network from which other attacks can be 797 mounted. The traffic analysis attack on a LLN may be passive and 798 relying on the ability to read the immutable source/destination 799 routing information that must remain unencrypted to permit network 800 routing. Alternatively, attacks can be active through the injection 801 of unauthorized discovery traffic into the network. By implementing 802 authentication measures between communicating nodes, active traffic 803 analysis attacks can be prevented within the LLN thereby reducing 804 confidentiality vulnerabilities to those associated with passive 805 analysis. 807 One way in which passive traffic analysis attacks can be muted is 808 through the support of load balancing that allows traffic to a given 809 destination to be sent along diverse routing paths. Where the 810 routing protocol supports load balancing along multiple links at each 811 node, the number of routing permutations in a wide area network 812 surges thus increasing the cost of traffic analysis. Network 813 analysis through this passive attack will require a wider array of 814 analysis points and additional processing on the part of the 815 attacker. In LLNs, the diverse radio connectivity and dynamic links 816 (including potential frequency hopping) will help to further mitigate 817 traffic analysis attacks when load balancing is implemented. 819 The only means of fully countering a traffic analysis attack is 820 through the use of tunneling (encapsulation) where encryption is 821 applied across the entirety of the original packet source/destination 822 addresses. With tunneling there is a further requirement that the 823 encapsulating intermediate nodes apply an additional layer of routing 824 so that traffic arrives at the destination through dynamic routes. 825 For LLNs, memory and processing constraints as well as the 826 limitations of the communication channel will preclude both the 827 additional routing traffic overhead and the node implementation 828 required for tunneling countermeasures to traffic analysis. 830 5.1.4. Countering Physical Device Compromise 832 Given the distributed nature of LLNs, confidentiality of routing 833 assets and points of access will rely heavily on the security of the 834 routing devices. One means of precluding attacks on the physical 835 device is to prevent physical access to the node through other 836 external security means. However, given the environment in which 837 LLNs operate, preventing unauthorized access to the physical device 838 cannot be assured. Countermeasures must therefore be employed at the 839 device and component level so that routing/topology or neighbor 840 information and stored route information cannot be accessed even if 841 physical access to the node is obtained. 843 With the physical device in the possession of an attacker, 844 unauthorized information access can be attempted by probing internal 845 interfaces or device components. Device security must therefore move 846 to preventing the reading of device processor code or memory 847 locations without the appropriate security keys and in preventing the 848 access to any information exchanges occurring between individual 849 components. Information access will then be restricted to external 850 interfaces in which confidentiality, integrity and authentication 851 measures can be applied. 853 To prevent component information access, deployed routing devices 854 must ensure that their implementation avoids address or data buses 855 being connected to external general purpose input/output (GPIO) pins. 856 Beyond this measure, an important component interface to be protected 857 against attack is the Joint Test Action Group (JTAG) interface used 858 for component and populated circuit board testing after manufacture. 859 To provide security on the routing devices, components should be 860 employed that allow fuses on the JTAG interfaces to be blown to 861 disable access. This will raise the bar on unauthorized component 862 information access within a captured device. 864 At the device level a key component information exchange is between 865 the microprocessor and it associated external memory. While 866 encryption can be implemented to secure data bus exchanges, the use 867 of integrated physical packaging which avoids inter-component 868 exchanges (other than secure external device exchanges) will increase 869 routing security against a physical device interface attack. With an 870 integrated package and disabled internal component interfaces, the 871 level of physical device security can be controlled by managing the 872 degree to which the device packaging is protected against expert 873 physical decomposition and analysis. 875 The device package should be hardened such that attempts to remove 876 the integrated components will result in damage to access interfaces, 877 ports or pins that prevent retrieval of code or stored information. 878 The degree of VLSI or PCB package security through manufacture can be 879 selected as a tradeoff or desired security consistent with the level 880 of security achieved by measures applied for other routing assets and 881 points of access. With package hardening and restricted component 882 access countermeasures, the security level will be raised to that 883 provided by measures employed at the external communications 884 interfaces. 886 Another area of node interface vulnerability is that associated with 887 interfaces provided for remote software or firmware upgrades. This 888 may impact both routing information and routing/topology exchange 889 security where it leads to unauthorized upgrade or change to the 890 routing protocol running on a given node as this type of attack can 891 allow for the execution of compromised or intentionally malicious 892 routing code on multiple nodes. Countermeasures to this device 893 interface confidentiality attack needs to be addressed in the larger 894 context of node remote access security. This will ensure not only 895 the authenticity of the provided code (including routing protocol) 896 but that the process is initiated by an authorized (authenticated) 897 entity. 899 The above identified countermeasures against attacks on routing 900 information confidentiality through internal device interface 901 compromise must be part of the larger LLN system security as they 902 cannot be addressed within the routing protocol itself. Similarly, 903 the use of field tools or other devices that allow explicit access to 904 node information must implement security mechanisms to ensure that 905 routing information can be protected against unauthorized access. 906 These protections will also be external to the routing protocol and 907 hence not part of ROLL. 909 5.1.5. Countering Remote Device Access Attacks 911 Where LLN nodes are deployed in the field, measures are introduced to 912 allow for remote retrieval of routing data and for software or field 913 upgrades. These paths create the potential for a device to be 914 remotely accessed across the network or through a provided field 915 tool. In the case of network management a node can be directly 916 requested to provide routing tables and neighbor information. 918 To ensure confidentiality of the node routing information against 919 attacks through remote access, any device local or remote requesting 920 routing information must be authenticated to ensure authorized 921 access. Since remote access is not invoked as part of a routing 922 protocol security of routing information stored on the node against 923 remote access will not be addressable as part of the routing 924 protocol. 926 5.2. Integrity Attack Countermeasures 928 Integrity attack countermeasures address routing information 929 manipulation, as well as node identity and routing information 930 misuse. Manipulation can occur in the form of falsification attack 931 and physical compromise. To be effective, the following development 932 considers the two aspects of falsification, namely, the tampering 933 actions and the overclaiming and misclaiming content. The countering 934 of physical compromise was considered in the previous section and is 935 not repeated here. With regard to misuse, there are two types of 936 attacks to be deterred, identity attacks and replay attacks. 938 5.2.1. Countering Tampering Attacks 940 Tampering may occur in the form of altering the message being 941 transferred or the data stored. Therefore, it is necessary to ensure 942 that only authorized nodes can change the portion of the information 943 that is allowed to be mutable, while the integrity of the rest of the 944 information is protected, e.g., through well-studied cryptographic 945 mechanisms. 947 Tampering may also occur in the form of insertion or deletion of 948 messages during protocol changes. Therefore, the protocol needs to 949 ensure the integrity of the sequence of the exchange sequence. 951 The countermeasure to tampering needs to 953 o implement access control on storage; 955 o provide data integrity service to transferred messages and stored 956 data; 958 o include sequence number under integrity protection. 960 5.2.2. Countering Overclaiming and Misclaiming Attacks 962 Both overclaiming and misclaiming aim to introduce false routes or 963 topology that would not be generated by the network otherwise, while 964 there is not necessarily tampering. The requisite for a counter is 965 the capability to determine unreasonable routes or topology. 967 The counter to overclaiming and misclaiming may employ 969 o comparison with historical routing/topology data; 971 o designs which restrict realizable network topologies. 973 5.2.3. Countering Identity (including Sybil) Attacks 975 Identity attacks, sometimes simply called spoofing, seek to gain or 976 damage assets whose access is controlled through identity. In 977 routing, an identity attacker can illegitimately participate in 978 routing exchanges, distribute false routing information, or cause an 979 invalid outcome of a routing process. 981 A perpetrator of Sybil attacks assumes multiple identities. The 982 result is not only an amplification of the damage to routing, but 983 extension to new areas, e.g., where geographic distribution is 984 explicit or implicit an asset to an application running on the LLN. 986 The counter of identity attacks need to ensure the authenticity and 987 liveliness of the parties of a message exchange; the measure may use 988 shared key or public key based authentication scheme. On the one 989 hand, the large-scale nature of the LLNs makes the network-wide 990 shared key scheme undesirable from a security perspective; on the 991 other hand, public-key based approaches generally require more 992 computational resources. Each system will need to make trade-off 993 decisions based on its security requirements. 995 5.2.4. Countering Routing Information Replay Attacks 997 In routing, message replay can result in false topology and/or 998 routes. The counter of replay attacks need to ensure the freshness 999 of the message. On the one hand, there are a number of mechanisms 1000 commonly used for countering replay. On the other hand, the choice 1001 should take into account how a particular mechanism is made available 1002 in a LLN. For example, many LLNs have a central source of time and 1003 have it distributed by relaying, such that secured time distribution 1004 becomes a prerequisite of using timestamping to counter replay. 1006 5.2.5. Countering Byzantine Routing Information Attacks 1008 Where a node is captured or compromized but continues to operate for 1009 a period with valid network security credentials, the potential 1010 exists for routing information to be manipulated. This compromise of 1011 the routing information could thus exist in spite of security 1012 countermeasures that operate between the peer routing devices. 1014 Consistent with the end-to-end principle of communications, such an 1015 attack can only be fully addressed through measures operating 1016 directly between the routing entities themselves or by means of 1017 external entities able to access and independently analyze the 1018 routing information. Verification of the authenticity and liveliness 1019 of the routing principals can therefore only provide a limited 1020 counter against internal (Byzantine) node attacks. 1022 For link state routing protocols where information is flooded 1023 countermeasures can be directly applied by the routing entities 1024 through the processing and comparison of link state information 1025 received from different peers. By comparing the link information 1026 from multiple sources decisions can be made by a routing node or 1027 external entity with regard to routing information validity. 1029 For distance vector protocols where information is aggregated at each 1030 routing node it is not possible for nodes to directly detect 1031 Byzantine information manipulation attacks from the routing 1032 information exchange. In such cases, the routing protocol must 1033 include and support indirect communications exchanges between non- 1034 adjacent routing peers to provide a secondary channel for performing 1035 routing information validation. S-RIP [Wan2004] is an example of the 1036 implementation of this type of dedicated routing protocol security 1037 where the correctness of aggregate distance vector information can 1038 only be validated by initiating confirmation exchanges directly 1039 between nodes that are not routing neighbors. 1041 Alternatively, an entity external to the routing protocol would be 1042 required to collect and audit routing information exchanges to detect 1043 the Byzantine attack. In the context of the current security 1044 framework, any protection against Byzantine routing information 1045 attacks will need to be directly included within the mechanisms of 1046 the ROLL routing protocol. This can be implemented where such an 1047 attack is considered relevant even within the physical device 1048 protections discussed in Section 5.1.4 1050 5.3. Availability Attack Countermeasures 1052 As alluded to before, availability requires that routing information 1053 exchanges and forwarding mechanisms be available when needed so as to 1054 guarantee a proper functioning of the network. This may, e.g., 1055 include the correct operation of routing information and neighbor 1056 state information exchanges, among others. We will highlight the key 1057 features of the security threats along with typical countermeasures 1058 to prevent or at least mitigate them. We will also note that an 1059 availability attack may be facilitated by an identity attack as well 1060 as a replay attack, as was addressed in Section 5.2.3 and 1061 Section 5.2.4, respectively. 1063 5.3.1. Countering HELLO Flood Attacks and ACK Spoofing Attacks 1065 HELLO Flood [Karlof2003],[I-D.suhopark-hello-wsn] and ACK Spoofing 1066 attacks are different but highly related forms of attacking a LLN. 1067 They essentially lead nodes to believe that suitable routes are 1068 available even though they are not and hence constitute a serious 1069 availability attack. 1071 The origin of facilitating a HELLO flood attack lies in the fact that 1072 many wireless routing protocols require nodes to send HELLO packets 1073 either upon joining or in regular intervals so as to announce or 1074 confirm their existence to the network. Those nodes that receive the 1075 HELLO packet assume that they are within radio range of the 1076 transmitter by means of a bidirectional communication link. 1078 With this in mind, a malicious node can send or replay HELLO packets 1079 using a higher transmission power. That creates the false illusion 1080 of being a neighbor to an increased number of nodes in the network, 1081 thereby effectively increasing its unidirectional neighborhood 1082 cardinality. The high quality of the falsely advertised link may 1083 coerce nodes to route data via the malicious node. However, those 1084 affected nodes, for which the malicious node is out of radio range, 1085 never succeed in their delivery and the packets are effectively 1086 dropped. The symptoms are hence similar to those of a sinkhole, 1087 wormhole and selective forwarding attack. 1089 A malicious HELLO flood attack clearly distorts the network topology. 1090 It thus affects protocols building and maintaining the network 1091 topology as well as routing protocols as such, since the attack is 1092 primarily targeted on protocols that require sharing of information 1093 for topology maintenance or flow control. 1095 To counter HELLO flood attacks, several mutually non-exclusive 1096 methods are feasible: 1098 o restricting neighborhood cardinality; 1100 o facilitating multipath routing; 1102 o verifying bidirectionality. 1104 Restricting the neighborhood cardinality prevents malicious nodes 1105 from having an extended set of neighbors beyond some tolerated 1106 threshold and thereby preventing topologies to be built where 1107 malicious nodes have an extended neighborhood set. Furthermore, as 1108 shown in [I-D.suhopark-hello-wsn], if the routing protocol supports 1109 multiple paths from a sensing node towards several gateways then 1110 HELLO flood attacks can also be diminished; however, the energy- 1111 efficiency of such approach is clearly sub-optimal. Finally, 1112 verifying that the link is truly bidirectional by means of, e.g., an 1113 ACK handshake and appropriate security measures ensures that a 1114 communication link is only established if not only the affected node 1115 is within range of the malicious node but also vice versa. Whilst 1116 this does not really eliminate the problem of HELLO flooding, it 1117 greatly reduces the number of affected nodes and the probability of 1118 such an attack succeeding. 1120 As for the latter, the adversary may spoof the ACK messages to 1121 convince the affected node that the link is truly bidirectional and 1122 thereupon drop, tunnel or selectively forward messages. Such ACK 1123 spoofing attack is possible if the malicious node has a receiver 1124 which is significantly more sensitive than that of a normal node, 1125 thereby effectively extending its range. Since an ACK spoofing 1126 attack facilitates a HELLO flood attack, similar countermeasure are 1127 applicable here. Viable counter and security measures for both 1128 attacks have been exposed in [I-D.suhopark-hello-wsn]. 1130 5.3.2. Countering Overload Attacks 1132 Overload attacks are a form of DoS attack in that a malicious node 1133 overloads the network with irrelevant traffic, thereby draining the 1134 nodes' energy budget quicker. It thus significantly shortens the 1135 network lifetime and hence constitutes another serious availability 1136 attack. 1138 With energy being one of the most precious assets of LLNs, targeting 1139 its availability is a fairly obvious attack. Another way of 1140 depleting the energy of a LLN node is to have the malicious node 1141 overload the network with irrelevant traffic. This impacts 1142 availability since certain routes get congested which 1144 o renders them useless for affected nodes and data can hence not be 1145 delivered; 1147 o makes routes longer as shortest path algorithms work with the 1148 congested network; 1150 o depletes nodes quicker and thus shortens the network's 1151 availability at large. 1153 Overload attacks can be countered by deploying a series of mutually 1154 non-exclusive security measures: 1156 o introduce quotas on the traffic rate each node is allowed to send; 1158 o isolate nodes which send traffic above a certain threshold; 1160 o allow only trusted data to be received and forwarded. 1162 As for the first one, a simple approach to minimize the harmful 1163 impact of an overload attack is to introduce traffic quotas. This 1164 prevents a malicious node from injecting a large amount of traffic 1165 into the network, even though it does not prevent said node from 1166 injecting irrelevant traffic at all. Another method is to isolate 1167 nodes from the network once it has been detected that more traffic is 1168 injected into the network than allowed by a prior set or dynamically 1169 adjusted threshold. Finally, if communication is sufficiently 1170 secured, only trusted nodes can receive and forward traffic which 1171 also lowers the risk of an overload attack. 1173 5.3.3. Countering Selective Forwarding Attacks 1175 Selective forwarding attacks are another form of DoS attack which 1176 impacts the routing path availability. 1178 An insider malicious node basically blends neatly in with the network 1179 but then may decide to forward and/or manipulate certain packets. If 1180 all packets are dropped, then this attacker is also often referred to 1181 as a "black hole". Such a form of attack is particularly dangerous 1182 if coupled with sinkhole attacks since inherently a large amount of 1183 traffic is attracted to the malicious node and thereby causing 1184 significant damage. An outside malicious node would selectively jam 1185 overheard data flows, where the thus caused collisions incur 1186 selective forwarding. 1188 Selective Forwarding attacks can be countered by deploying a series 1189 of mutually non-exclusive security measures: 1191 o multipath routing of the same message over disjoint paths; 1193 o dynamically select the next hop from a set of candidates. 1195 The first measure basically guarantees that if a message gets lost on 1196 a particular routing path due to a malicious selective forwarding 1197 attack, there will be another route which successfully delivers the 1198 data. Such method is inherently suboptimal from an energy 1199 consumption point of view. The second method basically involves a 1200 constantly changing routing topology in that next-hop routers are 1201 chosen from a dynamic set in the hope that the number of malicious 1202 nodes in this set is negligible. 1204 5.3.4. Countering Sinkhole Attacks 1206 In sinkhole attacks, the malicious node manages to attract a lot of 1207 traffic mainly by advertising the availability of high-quality links 1208 even though there are none. It hence constitutes a serious attack on 1209 availability. 1211 The malicious node creates a sinkhole by attracting a large amount 1212 of, if not all, traffic from surrounding neighbors by advertising in 1213 and outwards links of superior quality. Affected nodes hence eagerly 1214 route their traffic via the malicious node which, if coupled with 1215 other attacks such as selective forwarding, may lead to serious 1216 availability and security breaches. Such an attack can only be 1217 executed by an inside malicious node and is generally very difficult 1218 to detect. An ongoing attack has a profound impact on the network 1219 topology and essentially becomes a problem of flow control. 1221 Sinkhole attacks can be countered by deploying a series of mutually 1222 non-exclusive security measures: 1224 o use geographical insights for flow control; 1226 o isolate nodes which receive traffic above a certain threshold; 1228 o dynamically pick up next hop from set of candidates; 1230 o allow only trusted data to be received and forwarded. 1232 Whilst most of these countermeasures have been discussed before, the 1233 use of geographical information deserves further attention. 1234 Essentially, if geographic positions of nodes are available, then the 1235 network can assure that data is actually routed towards the sink(s) 1236 and not elsewhere. On the other hand, geographic position is a 1237 sensitive information that may have security and/or privacy 1238 consequences. 1240 5.3.5. Countering Wormhole Attacks 1242 In wormhole attacks at least two malicious nodes shortcut or divert 1243 the usual routing path by means of a low-latency out-of-band channel. 1244 This changes the availability of certain routing paths and hence 1245 constitutes a serious security breach. 1247 Essentially, two malicious insider nodes use another, more powerful, 1248 radio to communicate with each other and thereby distort the would- 1249 be-agreed routing path. This distortion could involve shortcutting 1250 and hence paralyzing a large part of the network; it could also 1251 involve tunneling the information to another region of the network 1252 where there are, e.g., more malicious nodes available to aid the 1253 intrusion or where messages are replayed, etc. In conjunction with 1254 selective forwarding, wormhole attacks can create race conditions 1255 which impact topology maintenance, routing protocols as well as any 1256 security suits built on "time of check" and "time of use". 1258 Wormhole attacks are very difficult to detect in general but can be 1259 mitigated using similar strategies as already outlined above in the 1260 context of sinkhole attacks. 1262 6. ROLL Security Features 1264 The assessments and analysis in Section 4 examined all areas of 1265 threats and attacks that could impact routing, and the 1266 countermeasures presented in Section 5 were reached without confining 1267 the consideration to means only available to routing. This section 1268 puts the results into perspective and provides a framework for 1269 addressing the derived set of security objectives that must be met by 1270 the ROLL protocol. It bears emphasizing that the target here is a 1271 generic ROLL protocol and the normative keywords are mainly to convey 1272 the relative level of urgency of the features specified. 1274 The first part of this section, Section 6.1 to Section 6.3, is a 1275 prescription of ROLL security features of measures that can be 1276 addressed as part of the routing protocol itself. As routing is one 1277 component of a LLN system, the actual strength of the security 1278 services afforded to it should be made to conform to each system's 1279 security policy; how a design may address the needs of the urban, 1280 industrial, home automation, and building automation application 1281 domains also needs to be considered. The second part of this 1282 section, Section 6.4 and Section 6.5, discusses system security 1283 aspects that may impact routing but that also require considerations 1284 beyond the routing protocol, as well as potential approaches. 1286 6.1. Confidentiality Features 1288 With regard to confidentiality, protecting the routing/topology 1289 information from eavesdropping or unauthorized exposure is not 1290 directly essential to maintaining the routing function. Breaches of 1291 confidentiality may lead to other attacks or the focusing of an 1292 attacker's resources (see Section 4.1) but does not of itself 1293 directly undermine the operation of the routing function. However, 1294 to protect against, and improve vulnerability against other more 1295 direct attacks, routing information confidentiality should be 1296 protected. Thus, a secured ROLL protocol 1298 o SHOULD provide payload encryption; 1300 o MAY provide tunneling; 1302 o MAY provide load balancing; 1304 o SHOULD provide privacy, e.g., when geographic information is used. 1306 Where confidentiality is incorporated into the routing exchanges, 1307 encryption algorithms and key lengths need to be specified in 1308 accordance of the level of protection dictated by the routing 1309 protocol and the associated application domain transport network. In 1310 terms of the life time of the keys, the opportunity to periodically 1311 change the encryption key increases the offered level of security for 1312 any given implementation. However, where strong cryptography is 1313 employed, physical, procedural, and logical data access protection 1314 considerations may have more significant impact on cryptoperiod 1315 selection than algorithm and key size factors. Nevertheless, in 1316 general, shorter cryptoperiods, during which a single key is applied, 1317 will enhance security. 1319 Given the mandatory protocol requirement to implement routing node 1320 authentication as part of routing integrity (see Section 6.2), key 1321 exchanges may be coordinated as part of the integrity verification 1322 process. This provides an opportunity to increase the frequency of 1323 key exchange and shorten the cryptoperiod as a compliment to the key 1324 length and encryption algorithm required for a given application 1325 domain. For LLNs, the coordination of confidentiality key management 1326 with the implementation of node device authentication can thus reduce 1327 the overhead associated with supporting data confidentiality. A new 1328 ciphering key may therefore be concurrently generated or updated in 1329 conjunction with the mandatory authentication exchange occurring with 1330 each routing peer association. 1332 6.2. Integrity Features 1334 The integrity of routing information provides the basis for ensuring 1335 that the function of the routing protocol is achieved and maintained. 1336 To protect integrity, a secured ROLL protocol 1338 o MUST verify message integrity; 1340 o MUST verify the authenticity and liveliness of both principals of 1341 a connection; 1343 o MUST verify message sequence. 1345 Depending on the nature of the routing protocol, e.g., distance 1346 vector or link state, additional measures may be necessary when the 1347 validity of the routing information is of concern. Specifically, 1348 verification of routing peer authenticity and liveliness can be used 1349 to build a "chain of trust" along the path the routing information 1350 flows, such that network-wide information is validated through the 1351 concatenation of trust established at each individual routing peer 1352 exchange. This is particularly important in the case of distance 1353 vector-based routing protocols, where information is updated at 1354 intermediate nodes, In such cases, there are no direct means within 1355 routing for a receiver to verify the validity of the routing 1356 information beyond the current exchange; as such, nodes would need to 1357 be able to communicate and request information from non-adjacent 1358 peers (see [Wan2004]) to provide information integrity assurances. 1359 With link state-based protocols, on the other hand, routing 1360 information can be signed at the source thus providing a means for 1361 validating information that originates beyond a routing peer. 1362 Therefore, where necessary, a secured ROLL protocol 1363 o MAY use security auditing mechanisms that are external to routing 1364 to verify the validity of the routing information content 1365 exchanged among routing peers. 1367 6.3. Availability Features 1369 Availability of routing information is linked to system and network 1370 availability which in the case of LLNs require a broader security 1371 view beyond the requirements of the routing entities (see 1372 Section 6.5). Where availability of the network is compromised, 1373 routing information availability will be accordingly affected. 1374 However, to specifically assist in protecting routing availability 1376 o MAY restrict neighborhood cardinality; 1378 o MAY use multiple paths; 1380 o MAY use multiple destinations; 1382 o MAY choose randomly if multiple paths are available; 1384 o MAY set quotas to limit transmit or receive volume; 1386 o MAY use geographic insights for flow control. 1388 6.4. Additional Related Features 1390 If a LLN employs multicast and/or anycast, it MUST secure these 1391 protocols with the services listed in this sections. Furthermore, 1392 the nodes MUST provide adequate physical tamper resistance to ensure 1393 the integrity of stored routing information. 1395 The functioning of the security services requires keys and 1396 credentials. Therefore, even though not directly a ROLL security 1397 requirement, a LLN must include a process for key and credential 1398 distribution; a LLN is encouraged to have procedures for their 1399 revocation and replacement. 1401 6.5. Consideration on Matching Application Domain Needs 1403 As routing is one component of a LLN system, the actual strength of 1404 the security services afforded to it should be made to conform to 1405 each system's security policy; how a design may address the needs of 1406 the urban, industrial, home automation, and building automation 1407 application domains is considered as part of the security 1408 architecture in Section 6.5.1. 1410 The development so far takes into account collectively the impacts of 1411 the issues gathered from [RFC5548], [RFC5673], 1412 [I-D.ietf-roll-home-routing-reqs], and 1413 [I-D.ietf-roll-building-routing-reqs]. The following two subsections 1414 first consider from an architectural perspective how the security 1415 design of a ROLL protocol may be made to adapt to the four 1416 application domains, and then examine mechanism and protocol 1417 operations issues. 1419 6.5.1. Security Architecture 1421 The first challenge for a ROLL protocol security design is to have an 1422 architecture that can adequately address a set of very diversified 1423 needs. It is mainly a consequence of the fact that there are both 1424 common and non-overlapping requirements from the four application 1425 domains, while, conceivably, each individual application will present 1426 yet its own unique constraints. 1428 For a ROLL protocol, the security requirements defined in Section 6.1 1429 to Section 6.4 can be addressed at two levels: 1) through measures 1430 implemented directly within the routing protocol itself and initiated 1431 and controlled by the routing protocol entities; or 2) through 1432 measures invoked on behalf of the routing protocol entities but 1433 implemented within the transport network over which the protocol 1434 exchanges occur. 1436 Where security is directly implemented as part of the routing 1437 protocol the security requirements configured by the user (system 1438 administrator) will operate independent of the underlying transport 1439 network. OSPFv2 [RFC2328] is an example of such an approach in which 1440 security parameters are exchanged and assessed within the routing 1441 protocol messages. In this case, the mechanism may be, e.g., a 1442 header containing security material of configurable security 1443 primitives in the fashion of OSPFv2 or RIPv2 [RFC2453]. Where IPsec 1444 [RFC4301] is employed to secure the network, the included protocol- 1445 specific (OSPF or RIP) security elements are in addition to and 1446 independent of those at the network layer. In the case of LLNs or 1447 other networks where system security mandates protective mechanisms 1448 at other lower layers of the transport network, security measures 1449 implemented as part of the routing protocol will be redundant to 1450 security measures implemented elsewhere as part of the transport 1451 network. 1453 Security mechanisms built into the routing protocol can ensure that 1454 all desired countermeasures can be directly addressed by the protocol 1455 all the way to the endpoint of the routing exchange. In particular, 1456 routing protocol Byzantine attacks by a compromised node that retains 1457 valid network security credentials can only be detected at the level 1458 of the information exchanged within the routing protocol. Such 1459 attacks aimed the manipulation of the routing information can only be 1460 fully addressed through measures operating directly between the 1461 routing entities themselves or external entities able to access and 1462 analyze the routing information (see discussion in Section 5.2.5). 1464 On the other hand, it is more desirable from a LLN device perspective 1465 that the ROLL protocol is integrated into the framework of an overall 1466 system architecture where the security facility may be shared by 1467 different applications and/or across layers for efficiency, and where 1468 security policy and configurations can be consistently specified. 1469 See, for example, considerations made in RIPng [RFC2080] or the 1470 approach presented in [Messerges2003]. 1472 Where the routing protocol is able to rely on security measures 1473 configured with the transport network, greater system efficiency can 1474 be realized by avoiding potentially redundant security. Relying on 1475 an open trust model [Messerges2003], the security requirements of the 1476 routing protocol can be more flexibly met at different layers of the 1477 transport network; measures that must be applied to protect the 1478 communications network are concurrently able to provide the needed 1479 routing protocol protection. 1481 In addition, in the context of the different application domains, it 1482 allows the level of security applied for routing to be consistent 1483 with that needed for protecting the network itself. For example, 1484 where AES-128 is deemed the appropriate standard for network 1485 confidentiality of data exchanges at the link layer, that level of 1486 security is automatically afforded to routing protocol exchanges. 1487 Similarly, where SHA-1 is stipulated as the standard required for 1488 authenticating routing protocol peers, the use of SHA-1 at the 1489 network layer between communicating routing devices automatically 1490 meets the routing protocol security requirement within the context of 1491 open trust across layers within the device. 1493 A ROLL protocol MUST be made flexible by a design that offers the 1494 configuration facility so that the user (network administrator) can 1495 choose the security settings that match the application's needs. 1496 Furthermore, in the case of LLNs that flexibility should extend to 1497 allowing the routing protocol security requirements to be met by 1498 measures applied at different protocol layers, provided the 1499 identified requirements are collectively met. 1501 Since Byzantine attacks that can affect the validity of the 1502 information content exchanged between routing entities can only be 1503 directly countered at the routing protocol level, the ROLL protocol 1504 may support mechanisms for verifying routing data validity that 1505 extends beyond the chain of trust created through device 1506 authentication. This protocol-specific security mechanism should be 1507 made optional within the protocol allowing it to be invoked according 1508 to the given routing protocol and application domain and as selected 1509 by the system user. All other ROLL security mechanisms needed to 1510 meet the above identified routing security requirements should be 1511 flexibly implemented within the transport network (at the IP network 1512 layer or higher or lower protocol layers(s)) according to the 1513 particular application domain and user network configuration. 1515 Based on device capabilities and the spectrum of operating 1516 environments it would be difficult for a single fixed security design 1517 to be applied to address the diversified needs of the four ROLL 1518 application domains without forcing a very low common denominator set 1519 of requirements. On the other hand, providing four individual domain 1520 designs that attempt to a priori match each individual domain is also 1521 very likely to provide a suitable answer given the degree of network 1522 variability even within a given domain. Instead, the framework 1523 implementation approach recommended for optional, routing protocol- 1524 specific measures together with flexible transport network mechanisms 1525 can be the most effective. This approach allows countermeasures 1526 against internal attacks to be applied in environments where 1527 applicable threats exist. At the same time, it allows routing 1528 protocol security to be configured through measures implemented 1529 within the transport network that is commensurate and consistent with 1530 the level and strength applied in the particular application domain 1531 networks. 1533 6.5.2. Mechanisms and Operations 1535 With an architecture allowing different configurations to meet the 1536 application domain needs, the task is then to find suitable 1537 mechanisms. For example, one of the main problems of synchronizing 1538 security states of sleepy nodes, as listed in the last subsection, 1539 lies in difficulties in authentication; these nodes may not have 1540 received in time the most recent update of security material. 1541 Similarly, the issues of minimal manual configuration, prolonged 1542 rollout and delayed addition of nodes, and network topology changes 1543 also complicate security management. In such case the ROLL protocol 1544 may need to bootstrap the authentication process and allow for 1545 flexible expiration scheme of authentication credentials. This 1546 exemplifies the need for the coordination and interoperation between 1547 the requirements of the ROLL routing protocol and that of the system 1548 security elements. 1550 Similarly, the vulnerability brought forth by some special-function 1551 nodes, e.g., gateways/sinks requires the assurance, particularly, of 1552 the availability of communication channels and node resources, or 1553 that the neighbor discovery process operates without undermining 1554 routing availability. 1556 There and other factors which are not part of a ROLL routing protocol 1557 can still affect its operation. This includes elements such as 1558 weaker barrier to accessing the data or security material stored on 1559 the nodes through physical means; therefore, the internal and 1560 external interfaces of a node need to be adequate for guarding the 1561 integrity, and possibly the confidentiality, of stored information, 1562 as well as the integrity of routing and route generation processes. 1564 Figure 2 provides an overview of the larger context of system 1565 security and the relationship between ROLL requirements and measures 1566 and those that relate to the LLN system. 1568 Security Services for 1569 ROLL-Addressable 1570 Security Requirements 1571 | | 1572 +---+ +---+ 1573 Node_i | | Node_j 1574 _____v___ ___v_____ 1575 Specify Security / \ / \ Specify Security 1576 Requirements | Routing | | Routing | Requirements 1577 +---------| Protocol| | Protocol|---------+ 1578 | | Entity | | Entity | | 1579 | \_________/ \_________/ | 1580 | | | | 1581 |ROLL-Specified | | ROLL-Specified| 1582 ---Interface | | Interface--- 1583 | ...................................... | 1584 | : | | : | 1585 | : +-----+----+ +----+-----+ : | 1586 | : |Transport/| |Transport/| : | 1587 ____v___ : +>|Network | |Network |<+ : ___v____ 1588 / \ : | +-----+----+ +----+-----+ | : / \ 1589 | |-:-+ | | +-:-| | 1590 |Security| : +-----+----+ +----+-----+ : |Security| 1591 +->|Services|-:-->| Link | | Link |<--:-|Services|<-+ 1592 | |Entity | : +-----+----+ +----+-----+ : |Entity | | 1593 | | |-:-+ | | +-:-| | | 1594 | \________/ : | +-----+----+ +----+-----+ | : \________/ | 1595 | : +>| Physical | | Physical |<+ : | 1596 Application : +-----+----+ +----+-----+ : Application 1597 Domain User : | | : Domain User 1598 Configuration : |__Comm. Channel_| : Configuration 1599 : : 1600 ...Transport Network.................. 1602 Figure 2: LLN Device Security Model 1604 7. Application of ROLL Security Framework to RPL 1606 This section applies the assessments given in Section 6 to RPL as an 1607 illustration of the application of the LLN security framework. 1609 Specializing the approach used in Section 3.1, Figure 3 gives a 1610 level-1 data flow diagram representation of RPL to show the routing 1611 "assets" and "points of access" that may be vulnerable and need to be 1612 protected. 1614 ............................................. 1615 : : 1616 |Multicast : : 1617 Group_i or : : 1618 Node_i|<------->(DIO/DIS/DAO)<--------------+ : 1619 : ^ | : 1620 : | ______V______ : 1621 : | Candidate : 1622 : V Neighbor List : 1623 : (RPL Control incl. ------+------ : 1624 : Trickle Timer, | : 1625 : Loop Avoidance) V : 1626 : ^ (Route Generation) : 1627 : | | : 1628 : | ______V______ : 1629 : +-------+ Routing Table : 1630 : | ------+------ : 1631 : | | : 1632 : RPL on Node_j | | : 1633 ...................|.............|........... 1634 | | 1635 |Forwarding V | 1636 To/From Node_k|<------>(Read/Write | 1637 Flow Label)<--------+ 1639 Figure 3: Data Flow Diagram of RPL 1641 From Figure 3, it is seen that threats to the proper operation of RPL 1642 are realized through attacks on its DIO, DIS, and DAO messages, as 1643 well as on the information the protocol places on the IPv6 Flow 1644 Labels. As set forth in Section 6.1 to Section 6.4, the base 1645 security requirements concern message integrity, authenticity and 1646 liveliness of the principals of a connection, and protection against 1647 message replay; message encryption may be desirable. The security 1648 objectives for RPL are therefore to ensure that 1650 1. participants of the DIO, DIS, and DAO message exchanges are 1651 authentic; 1653 2. the received DIO, DIS, and DAO messages are not modified during 1654 transportation; 1656 3. the received DIO, DIS, and DAO messages are not retransmissions 1657 of previous messages; 1659 4. the content of the DIO, DIS, and DAO messages may be made legible 1660 to only authorized entities. 1662 In meeting the above objectives, RPL also needs to provide tunable 1663 mechanisms both to allow matching the security afforded to the 1664 application domain requirements and to enable efficient use of system 1665 resources, as discussed in Section 6.5.1 and Section 6.5.2. 1667 The functions of the different RPL messages and information placed 1668 within the user data plane Flow Labels are factors that can be taken 1669 into account when deciding the optional security features and levels 1670 of strength to be afforded. For example, the DIO messages build 1671 routes to roots while the DAO messages support the building of 1672 downward routes to leaf nodes. Consequently, there may be 1673 application environments in which the directions of the routes have 1674 different importance and thus warrant the use of different security 1675 features and/or strength. In other words, it may be desirable to 1676 have an RPL security design that extends the tunability of the 1677 security features and strengths to message types. The use of a per- 1678 message security specification will allow flexibility in permitting 1679 application-domain security choices as well as overall tunability. 1681 8. IANA Considerations 1683 This memo includes no request to IANA. 1685 9. Security Considerations 1687 The framework presented in this document provides security analysis 1688 and design guidelines with a scope limited to ROLL. Security 1689 services are identified as requirements for securing ROLL. The 1690 results are applied to RPL, with consequent recommendations. 1692 10. Acknowledgments 1694 The authors would like to acknowledge the review and comments from 1695 Rene Struik. 1697 11. References 1699 11.1. Normative References 1701 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 1702 January 1997. 1704 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1705 Requirement Levels", BCP 14, RFC 2119, March 1997. 1707 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1709 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1710 November 1998. 1712 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1713 Internet Protocol", RFC 4301, December 2005. 1715 11.2. Informative References 1717 [Huang2003] 1718 Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. 1719 Zhang, "Fast Authenticated Key Establishment Protocols for 1720 Self-Organizing Sensor Networks", in Proceedings of the 1721 2nd ACM International Conference on Wireless Sensor 1722 Networks and Applications, San Diego, CA, USA, pp. 141- 1723 150, Sept. 19 2003. 1725 [I-D.ietf-roll-building-routing-reqs] 1726 Martocci, J., Riou, N., Mil, P., and W. Vermeylen, 1727 "Building Automation Routing Requirements in Low Power and 1728 Lossy Networks", draft-ietf-roll-building-routing-reqs-08 1729 (work in progress), December 2009. 1731 [I-D.ietf-roll-home-routing-reqs] 1732 Brandt, A. and J. Buron, "Home Automation Routing 1733 Requirements in Low Power and Lossy Networks", 1734 draft-ietf-roll-home-routing-reqs-10 (work in progress), 1735 January 2010. 1737 [I-D.ietf-roll-rpl] 1738 Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing 1739 Protocol for Low power and Lossy Networks", 1740 draft-ietf-roll-rpl-06 (work in progress), February 2010. 1742 [I-D.ietf-roll-terminology] 1743 Vasseur, J., "Terminology in Low power And Lossy 1744 Networks", draft-ietf-roll-terminology-02 (work in 1745 progress), October 2009. 1747 [I-D.suhopark-hello-wsn] 1748 Park, S., "Routing Security in Sensor Network: HELLO Flood 1749 Attack and Defense", draft-suhopark-hello-wsn-00 (work in 1750 progress), December 2005. 1752 [Karlof2003] 1753 Karlof, C. and D. Wagner, "Secure routing in wireless 1754 sensor networks: attacks and countermeasures", Elsevier 1755 AdHoc Networks Journal, Special Issue on Sensor Network 1756 Applications and Protocols, 1(2):293-315, September 2003. 1758 [Messerges2003] 1759 Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., Struik, 1760 R., and E. Callaway, "Low-Power Security for Wireless 1761 Sensor Networks", in Proceedings of the 1st ACM Workshop 1762 on Security of Ad Hoc and Sensor Networks, Fairfax, VA, 1763 USA, pp. 1-11, Oct. 31 2003. 1765 [Myagmar2005] 1766 Myagmar, S., Lee, AJ., and W. Yurcik, "Threat Modeling as 1767 a Basis for Security Requirements", in Proceedings of the 1768 Symposium on Requirements Engineering for Information 1769 Security (SREIS'05), Paris, France, pp. 94-102, Aug 1770 29, 2005. 1772 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1773 Routing Protocols", RFC 4593, October 2006. 1775 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1776 RFC 4949, August 2007. 1778 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 1779 "Routing Requirements for Urban Low-Power and Lossy 1780 Networks", RFC 5548, May 2009. 1782 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 1783 "Industrial Routing Requirements in Low-Power and Lossy 1784 Networks", RFC 5673, October 2009. 1786 [Wan2004] Wan, T., Kranakis, E., and PC. van Oorschot, "S-RIP: A 1787 Secure Distance Vector Routing Protocol", in Proceedings 1788 of the 2nd International Conference on Applied 1789 Cryptography and Network Security, Yellow Mountain, China, 1790 pp. 103-119, Jun. 8-11 2004. 1792 Authors' Addresses 1794 Tzeta Tsao (editor) 1795 Eka Systems 1796 20201 Century Blvd. Suite 250 1797 Germantown, Maryland 20874 1798 USA 1800 Email: tzeta.tsao@ekasystems.com 1801 Roger K. Alexander (editor) 1802 Eka Systems 1803 20201 Century Blvd. Suite 250 1804 Germantown, Maryland 20874 1805 USA 1807 Email: roger.alexander@ekasystems.com 1809 Mischa Dohler (editor) 1810 CTTC 1811 Parc Mediterrani de la Tecnologia, Av. Canal Olimpic S/N 1812 Castelldefels, Barcelona 08860 1813 Spain 1815 Email: mischa.dohler@cttc.es 1817 Vanesa Daza (editor) 1818 Universitat Pompeu Fabra 1819 P/ Circumval.lacio 8, Oficina 308 1820 Barcelona 08003 1821 Spain 1823 Email: vanesa.daza@upf.edu 1825 Angel Lozano (editor) 1826 Universitat Pompeu Fabra 1827 P/ Circumval.lacio 8, Oficina 309 1828 Barcelona 08003 1829 Spain 1831 Email: angel.lozano@upf.edu