idnits 2.17.00 (12 Aug 2021) /tmp/idnits60725/draft-daniel-6lowpan-security-analysis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 15, 2011) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ieee802.15.4' is mentioned on line 667, but not defined == Missing Reference: 'Madden' is mentioned on line 673, but not defined == Missing Reference: 'Stajano' is mentioned on line 678, but not defined == Missing Reference: 'ZigBee' is mentioned on line 697, but not defined == Missing Reference: 'WSN' is mentioned on line 682, but not defined == Missing Reference: 'MAC802154' is mentioned on line 685, but not defined == Missing Reference: 'SEC802154' is mentioned on line 689, but not defined == Missing Reference: 'SECWSN' is mentioned on line 693, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-6lowpan-nd has been published as RFC 6775 -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 over Low Power WPAN (6lowpan) S. Park 3 Internet-Draft Samsung Electronics 4 Intended status: Informational K. Kim 5 Expires: September 16, 2011 Ajou University 6 W. Haddad (Ed.) 7 S. Chakrabarti 8 Ericsson 9 J. Laganier 10 Juniper 11 March 15, 2011 13 IPv6 over Low Power WPAN Security Analysis 14 draft-daniel-6lowpan-security-analysis-05 16 Abstract 18 This document discusses possible threats and security options for 19 IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness 20 about security issues in IPv6 lowPan networks. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 16, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Challenges . . . . . . . . . . . . . . . . . . . . . 9 61 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 10 62 7. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 11 63 8. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 9. 6Lowpan Security Analysis . . . . . . . . . . . . . . . . . . 15 65 9.1. IEEE 802.15.4 Security analysis . . . . . . . . . . . . . 15 66 9.2. IP Security analysis . . . . . . . . . . . . . . . . . . . 16 67 10. Key Management in 6Lowpan . . . . . . . . . . . . . . . . . . 17 68 10.1. Existing Key Management Methods . . . . . . . . . . . . . 17 69 10.2. Issues With Key Management in 6Lowpan . . . . . . . . . . 18 70 11. Security Consideration in Bootstrapping a 6lowpan Node . . . . 19 71 12. Possible Scenarios Using Different Levels of Security . . . . 20 72 13. Security Considerations . . . . . . . . . . . . . . . . . . . 21 73 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 74 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 75 16. No I-D References . . . . . . . . . . . . . . . . . . . . . . 24 76 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 77 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 78 17.2. Informative References . . . . . . . . . . . . . . . . . . 25 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 81 1. Introduction 83 IEEE 802.15.4 [ieee802.15.4] specification defines Physical and MAC 84 layers targeted for the Low Rate Wireless Personal Area Networks (LR- 85 WPAN) using short distance applications with low power and low cost 86 communication networks, particularly for the short range applications 87 such as Wireless Sensors Network (WSN). In an IEEE 802.15.4 88 compliant WPAN, a central controller device, i.e., the PAN 89 coordinator, builds a WPAN with other devices within a small physical 90 space known as the personal operating system. IEEE 802.15.4 is 91 designed to support a variety of applications in personal area 92 networks; many of these applications are security sensitive. The 93 principal goal of the 6lowpan working group is to design IPv6 94 transmission over IEEE 802.15.4. 96 In fact, some of the IEEE 802.15.4 optional features actually reduce 97 security and implementation would be limited for their extensions. 98 The applications range from defense systems to building monitoring, 99 fire-safety, patient monitoring, etc. If the network is not secured, 100 an intruder can inject incorrect messages to trigger false 101 situations. 103 IEEE 802.15.4 working group is trying to improving the link-layer 104 security specification. However, this document will focus on 105 discussing different security threats from the 6lowpan perspective 106 and discuss different options for applying existing security methods 107 to overcome/alleviate these threats. The main goal is to provide a 108 trust model using both link-layer and IP layer security packages 109 whenever possible. 111 Designing a new security protocol for 6lowpan network is out of scope 112 of this document. However, the document states desired security 113 requirements, which can be fed into the appropriate IETF security 114 working group in order to design appropriate security protocols. 116 2. Requirements 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Terminology 124 This document uses terminology specific to IPv6 and DHCPv6 as defined 125 in the "Terminology" section of the DHCPv6 specification [RFC3315]. 127 4. Overview 129 As described in [RFC4919], unlike regular IP network, 6lowpan has 130 some special characteristics such as small packet size, low 131 bandwidth, large number of devices, etc. 6lowpan devices are 132 generally assumed to be resource-limited with respect to computation 133 power, storage, memory and especially battery life. One common 134 feature, which is worthy to remember is the disproportionately high 135 cost of transmitting information as compared to performing local 136 computation. For example, a Berkeley mote spends approximately 800 137 instructions as it does in sending a single bit [Madden]. It thus 138 become a main design criteria for 6lowpan to reduce the number of 139 bits forwarded by intermediate nodes, in order to extend the entire 140 network's lifetime as recharging may not be practical in some 141 deployment scenarios. 143 IEEE 802.15.4 nodes can operate in either secure mode or non-secure 144 mode. Two security modes are defined in the specification in order 145 to achieve different security objectives: 147 - Access Control List (ACL) mode which provides limited security 148 services and requires each device to maintain its own ACL. This mode 149 allows receiving frames only from nodes that are present in the 150 devices's ACL, i.e., considered as trusted nodes. Frames from non- 151 registered devices are filtered. However, cryptographic protection 152 is not provided in this mode. 154 - Secure mode provides all the security services according to the 155 defined security suite. It provides confidentiality of the frame 156 along with the message integrity, access control, and sequential 157 freshness. 159 However, the specification is not clear about key management methods, 160 state of ACL table in the event of power loss and support of group 161 keying in which case, network shared common key may be an answer for 162 the link layer security but is vulnerable to replay attacks launched 163 from stolen devices. Yet, in most common cases, network shared 164 keying can be the simple answer to the link layer security as it is 165 easily configurable among large number of devices. 167 The security aspect, however, seems a bit tradeoff in the 6lowpan 168 since security is always a costly function. This is particularly 169 true to low rate WPAN. Obviously, adding security makes the issue 170 even more challenging. For instance, when putting IPv6 on top of 171 6lowpan, it may seem possible to use IP security protocol [RFC4301] 172 and turn off the security mechanism defined by IEEE 802.15.4. But on 173 the other hand, IPsec is relatively mature for services at IP or 174 upper layers. Furthermore, due to their inherent properties and/or 175 constraints mentioned earlier, 6lowpan poses unique challenges to 176 which, traditional security techniques cannot be applied directly. 177 For example, public key cryptography primitives are typically avoided 178 (as being too expensive) as are relatively heavyweight conventional 179 encryption methods. 181 Consequently, it becomes questionable whether the 6lowpan devices can 182 support IPsec as it is. This document explains in the following 183 sections some of the difficulties resulting from adopting IPSec. 184 However, Layer 2 security must be used for all associated operations 185 such as MAC sub-layer association, beaconing, orphaning, etc. 187 While IPsec is mandatory with IPv6, considering the power constraints 188 and limited processing capabilities of IEEE802.15.4 capable devices, 189 IPsec is computationally expensive; Internet key exchange (IKEv2) 190 messaging described in [RFC5996] will not work well in 6lowpans as we 191 want to minimize the amount of signaling in these networks. Thus, 192 6lowpan may need to define its own keying management method(s) that 193 requires minimum overhead in packet-size and in number of signaling 194 messages exchange. IPsec will provide authentication and 195 confidentiality between end-nodes and across multiple lowpan-links, 196 and may be useful only when two nodes want to apply security to all 197 exchanged messages. However, in most cases, the security may be 198 requested at the application layer as needed, while other messages 199 can flow in the network without security overhead. 201 Attacks against 6lowpands can be classified into external attacks and 202 internal ones. In an external attack, the attacker is not an 203 authorized entity of the 6lowpan. External attacks can be further 204 divided into two categories: passive and active. Passive attacks 205 involve mainly eavesdropping on network's radio frequency range in an 206 attempt to discover sensitive information. Among active attacks 207 against 6lowpans, denial-of service (DoS) attack at the physical 208 layer can produce devastating consequences. To this end, the 209 attacker can broadcast a powerful signal within the WPAN zone, i.e., 210 jamming, and paralyzes part(s) or even the entire network. 212 An attacker may also disable a 6lowpan node (e.g., by smashing it!) 213 or capture one, extracts the key(s) and uses it for eavesdropping 214 purposes and/or to directly intervene at some point in time, by 215 injecting false but valid data in order to disturb the overall 216 system, e.g., trigger an undesired chain of events. Consequently, a 217 challenging issue facing 6lowpans is to provide resiliency against 218 node capture attack. 220 Data collection and dissemination being their ultimate goals, 221 6lowpans also highlights privacy concerns. In fact, as devices are 222 in general, getting smaller (i.e., easier to conceal) and cheaper 223 (i.e., easier to obtain), an obvious risk is that 6lowpan technology 224 might be used for privacy violation purposes, e.g., employers might 225 spy on their employees, neighbors might spy on each other. 227 Possible threats in 6lopwan include intrusion, sink-hole and replay 228 attacks. As in traditional networks, routing mechanisms in 6lowpan 229 present another window from which, an attacker might disrupt and 230 significantly degrade the 6lowpan overall performance. Attacks 231 against unsecure routing aim mainly to contaminate WPAN networks with 232 false routing information resulting in routing inconsistencies. A 233 malicious node can also snoop packets and then launch replay attacks 234 on the 6lowpan nodes. These attacks can cause harm especially when 235 the attacker is a high-power device, such as laptop. It can also 236 easily drain 6lowpan devices batteries by sending broadcast messages, 237 redirecting routes etc. 239 A possible solution to address security issues in the 6lowpan 240 networks might consist of implementing application level security, 241 e.g., SSL, on top of link layer security. In such case, link layer 242 security protects from intrusion and the application level security 243 protects from another user peeking at the data and against 244 impersonation. 246 5. Security Challenges 248 We summarize the security challenges in 6lowpan networks as it 249 follows (for more information about this section and the following 250 ones, please check the references): 252 - Minimizing resource consumption and maximizing security 253 performance. 255 - 6lowpan deployment enables link attacks ranging from passive 256 eavesdropping to active interfering. 258 - In-network processing involves intermediate nodes in end-to-end 259 information transfer. 261 - 6lowpan communication characteristics render traditional wired 262 based security schemes unsuitable. 264 6. Security Requirements 266 Security requirements for 6lowpan can be listed as it follows: 268 - Data Confidentiality: make information inaccessible to unauthorized 269 users. For example, a 6lowpan node should not leak some of its 270 collected data to neighboring networks. 272 - Data Authentication: since an adversary can easily inject messages, 273 the receiver needs to ensure that data are originated from a trusted 274 sources. 276 - Data Integrity: ensures that the received data is not altered in 277 transit by an adversary. 279 - Data freshness: this could mean data freshness as well as key 280 freshness. Informally, data freshness implies that each data is 281 recent, and it ensures that no adversary replayed old messages. 283 - Availability: ensures the survivability of network services to 284 (only) authorized parties when needed, despite a DoS attack(s). 286 - Robustness: ensures operation continuity despite abnormalities, 287 such as attacks, failed nodes, etc. 289 - Resiliency: is the network ability to provide and maintain an 290 acceptable level of security in case some nodes are compromised. 292 - Resistance: is the network ability to prevent the adversary from 293 gaining full control of the network by node replication attack in 294 case some nodes are compromised. 296 - Energy efficiency: a security scheme must be energy efficient so as 297 to maximize network lifetime. 299 - Assurance: is the ability to disseminate different information at 300 different assurance levels. 302 7. Security Threats 304 Most of the attacks and threats against user and data security in 305 6lowpan are plausible and MAY be very destructible in effect, because 306 of its wireless radio access and connectivity to the Internet. The 307 security analysis of 6lowpan starts with the appreciation of various 308 threats posed at respective ISO OSI layers. In this section, we 309 classify and discuss the threats in layer-wise order. The suggested 310 threat model assumes that the attacker is fully capable at all times 311 except during the deployment phase. 313 6lowpan is highly susceptible to physical attacks. i.e., threats due 314 to physical node destruction relocation and masking. By physical 315 attacks, one or multiple 6lowpan nodes can be knocked out 316 permanently, so the losses are irreversible. Physical attack can 317 extract cryptographic secrets from the associated circuitry, modify 318 programming in the nodes, and may allow the malicious node to take 319 control over them. These compromises can result into code 320 modification inside the node and to change the mission-oriented role 321 of full fledged networks, let alone sensors. 323 In 6lowpan environment, several types of DoS attacks can be triggered 324 in different layers. At the physical Layer, the DoS attacks can be 325 launched by tampering and jamming electromagnetic (EM) signals by 326 swarming the limited resources of 6lowpan devices with the high 327 resource devices very easily. 329 Attacks on MAC layer involves collision, exhaustion and unfairness. 330 Being always power hungry, 6lowpan devices try to sleep as often as 331 possible in order to conserve it. Such constraints open the door for 332 an attacker to let the device execute a large number of tasks in 333 order to deplete its battery. This is called "sleep deprivation 334 torture" [Stajano]. To achieve such goal, an attacker can for 335 example, target different destination devices with unnecessary 336 packets, possibly in other WPANs, regardless of whether the 337 destination WPAN and/or device actually exist or not. Such attack 338 can also lead to depleting the PAN coordinator battery power, i.e., 339 since the downlink packets have to be explicitly requested from the 340 PAN coordinator, this will keep it busy (as well as an eventual 341 destination). 343 An attack against network availability can consist of flooding the 344 network by simply transmitting a large number of large(st) packets 345 size. In such case, the attacker may degrade the network performance 346 and drastically reduce the throughput. 348 In WPAN specification, the replayed message is prevented by the 349 replay protection mechanism, i.e., sequential freshness. In a 350 replay-protection attack, the malicious node sends many frames 351 containing large counters to a particular receiver, which in turn 352 raises the replay counter up. Then, when a normal device sends a 353 frame with a lower frame counter, it will be rejected by the receiver 354 and thus, leading to DoS attack. 356 As the ACK frame integrity is not protected, it also opens the door 357 for a malicious node to prevent a legitimate device from receiving a 358 particular frame. This is possible by forging an ACK using the un- 359 encrypted sequence number from the data frame and sending it to the 360 source while creating enough interference, in order to prevent the 361 legitimate receiver from receiving the frame. In such scenario, the 362 source device is led to believe that the frame has been received. 364 A corrupted device can also attack the key distribution process since 365 the WPAN coordinator announces the IDs of devices who are about the 366 change the link key in plain-text in the beacon frame. Therefore, 367 the attacker can send request packet with the ID of the legitimate 368 node. The goal from such request is to push the coordinator to 369 trigger a key exchange process while the legitimate recipient may not 370 be ready. 372 Attacks against network layer fall into one of the following 373 categories: 375 - Spoofed, altered, or replayed routing information: in this attack, 376 the malicious node uses spoofing, altering and/or replaying to target 377 routing information exchanged between nodes in an attempt to create 378 routing loops, attract/repel network traffic, extend/shorten source 379 routes, generate false error messages, etc. 381 - Selective forwarding: in this attack, the malicious device may 382 refuse to forward certain messages (e.g., by dropping them). In this 383 case, neighboring devices may conclude that the malicious device has 384 failed and thus, try to seek another route. A more subtle form of 385 this attack is when the malicious device selectively forward packets 386 in which case, neighboring nodes won't be able to reach the 387 conclusion that another route is needed which in turn, would 388 encourage them to re-send the data packets. 390 - Sinkhole attack: in a sinkhole attack, the malicious device tries 391 to get all traffic from one particular area which can potentially 392 result in a DoS attack. In order to launch a sinkhole attack (aka 393 blackhole attack), the attacker can listen to requests for routes 394 then replies to the requesting nodes that it contains the high 395 quality or shortest path to the base station. Once the malicious 396 device is able to insert itself between the communicating nodes, he/ 397 she is able to do anything with the packets passing through it. In 398 fact, this attack can affect even the nodes that are spatially 399 located farther from the malicious node. 401 - Sybil attack: in a Sybil attack, a single node presents multiple 402 identities to other nodes in the WPAN. Sybil attacks pose a 403 significant threat to geographic routing protocols and MAY be 404 performed against the distributed storage, routing mechanism, data 405 aggregation, voting, fair resource-allocation and misbehavior 406 detection, etc. Note that it is not easy to detect a Sybil attack in 407 progress (measuring the usage of radio resources MAY lead to detect 408 it, though with very little probability). 410 - Wormhole attack: in a Wormhole attack, the attacker records packets 411 (or bits) at one location in the network and tunnels them to another 412 one. Such attacks can be devastating to the working of the 6lowpan 413 since it does not require compromising a node in the WPAN; instead, 414 it could be performed at the initial phase when 6lowpan nodes start 415 to discover the neighboring information. Wormhole attacks can target 416 for example, routing function or application. 418 - Neighbor Discovery attacks: a modified version of the IPv6 Neighbor 419 Discovery protocol (described in [RFC4861]) has been specifically 420 designed for WPAN. However, the modified version (described in 421 [I-D.ietf-6lowpan-nd] inherits threats which applies in the WPAN 422 deployment. This includes unsecured router advertisement, neighbor 423 discovery DoS attacks. Threats against neighbor discovery protocol 424 are described in [RFC3756]. 426 At the transport layer, attacks could be performed by half open and 427 half closed TCP segments. A malicious device can repeatedly forge 428 messages carrying sequence numbers or control flags which will 429 ultimately cause the endpoints to request retransmission of missed 430 frames. 432 8. Assumptions 434 [RFC4919] describes two security concerns as follows; 436 In Section 4.6 Security: Although IEEE 802.15.4 provides AES link 437 layer security, a complete end-to-end security is needed. 439 In Section 5 Goals: Security threats at different layers must be 440 clearly understood and documented. Bootstrapping of devices into a 441 secure network could also be considered given the location, limited 442 display, high density and ad hoc deployment of devices. 444 This document will meet the above considerations. 446 In addition, existing IP security technologies will be simplified to 447 be implemented on the 6lowpan small devices. 6lowpan security 448 architecture will shed off lots of fat from IP security technologies 449 whenever available. 451 IEEE 802.15.4 AES (Advanced Encryption Standard) will be used for 452 6lowpan security architecture in conjunction with IP security 453 whenever available. 455 9. 6Lowpan Security Analysis 457 In this section, both IEEE 802.15.4 MAC security and IP security are 458 tackled to search for a new 6lowpan trust models and available 459 solution spaces if feasible. The principal object of this analysis 460 is to improve 6lowpan security level as we use IP layer security 461 mechanism as possible regardless of 802.15.4 vulnerable MAC security. 462 802.15.4 MAC enhancement and amendment are not scope of this document 463 but IEEE 802 standard stuff. 465 9.1. IEEE 802.15.4 Security analysis 467 As mentioned earlier, IEEE 802.15.4 MAC layer provides security 468 services that are controlled by the MAC PIB (PAN Information Base). 469 For security purpose, the MAC sublayer maintains an access control 470 list (ACL) in its MAC PIB. By specifying a security suite in the ACL 471 for a communication peer, a device can indicate what security level 472 should be used (i.e., none, access control, data encryption, frame 473 integrity, etc.) for communications with that peer. 475 A critical function of IEEE 802.15.4 MAC is frame security. Frame 476 security is actually a set of optional services that may be provided 477 by the MAC to the upper layers (applications). The standard strikes 478 a balance between the need for these services in many applications, 479 and the desire to minimize the burden of their implementation on 480 those applications that do not need them. As described in [802.15.4- 481 ACM], if an application does not set any security parameters, then 482 security is not enabled by default. IEEE 802.15.4 defines four 483 packet types: beacon packets, data packets, acknowledgements packets 484 and control packets for the media access control layer. It does not 485 support security for acknowledgement packets. But on the other hand, 486 other packet types can optionally support integrity and 487 confidentiality protection for the packet's data field. 489 Due to the variety of applications targeted by IEEE 802.15.4, the 490 processes of authentication and key exchange are not defined in the 491 standard. Devices without the key cannot decrypt the encrypted 492 messages. 494 In addition, unsecured mode is suitable for some applications in 495 which implementation cost is important, and security is either not 496 required or obtained in other ways. An example of this is that all 497 6lowpan devices are assigned a default key by the administrator they 498 can exchange data encrypted with that key. This may work in some 499 situations, but this solution is not quite scalable. In this case, 500 802.15.4 node is very vulnerable. 502 The security service enables the MAC to select the devices with which 503 it is willing to communicate. The device may decide to communicate 504 with some devices, and not others. To minimize complexity, the 505 access control service is performed on an individual device basis, 506 rather than on groups or collections of devices. 508 Unlike file transfer or voice communication applications common with 509 other protocols, IEEE 802.15.4 applications often transmit messages 510 that do not convey secret information. 512 9.2. IP Security analysis 514 IPsec can guarantee integrity and optionally confidentiality of IP 515 (v4 or v6) packets exchanged between two peers. 517 Basically, IPsec works well on non-low-power devices which are not 518 subject to severe constraints on host software size, processing and 519 transmission capacities. IPsec supports AH for authenticating the IP 520 header and ESP for authenticating and encrypting the payload. The 521 main issues of using IPsec are two-fold: (1) processing power and (2) 522 key management. Since these tiny 6lowpan devices do not process huge 523 number of data or communicate with many different nodes, it is not 524 well understood if complete implementation of SADB, policy-database 525 and dynamic key-management protocol are appropriate for these small 526 battery powered devices. 528 Given existing constraints in 6lowpan environments, IPsec may not be 529 suitable to use in such environments, especially that 6lowpan node 530 may not be able to operate all IPsec algorithms on its own capability 531 either FFD or RFD. 533 Bandwidth is a very scarce resource in 6lowpan environments. The 534 fact that IPsec additionally requires another header (AH or ESP) in 535 every packet makes its use problematic in 6lowpan environments. 537 IPsec requires two communicating peers to share a secret key that is 538 typically established dynamically with the Internet Key Exchange 539 (IKEv2) protocol. Thus, it has an additional packet overhead 540 incurred by IKEv2 packets exchange. 542 As neighbor discovery protocol will be applied to 6lowpan, Secure 543 Neighbor Discovery (SeND) protocol [RFC3971] should be considered to 544 provide security in conjunction with 6lowpan NDP. SeND works well 545 over existing IP networks. However, the crypto-generated address 546 (CGA) (described in [RFC3972]) used in SeND is based on RSA based and 547 thus, requires larger packet-size and processing time than in the 548 case where Elliptic Curve Cryptography (ECC) keying algorithm is 549 used. Therefore, it could be reasonable to use the SeND protocol if 550 it is extended to support ECC for 6lowpan networks application. 552 10. Key Management in 6Lowpan 554 In order to provide security in 6lowpans, a robust encryption 555 mechanism MUST be in place. Only the non-tamperable keys can provide 556 an encryption infrastructure that is thorough enough to provide a 557 wide range of security services such as but not limited to 558 authentication, authorization, non-repudiation and prevention from 559 replay attacks. Key management issues are discussed in the following 560 section. 562 10.1. Existing Key Management Methods 564 The characteristics of 6lowpan communicating devices and resulting 565 WPANs, such as limited resources at the node and network level, lack 566 of physical protection, unattended operation, and a close interaction 567 with the physical environment, all make it infeasible to implement 568 some of the most popular key exchange techniques in their literal 569 forms for 6lowpans. In this section, we visit three widely known 570 schemes such as trusted-server scheme, pre-distribution scheme and 571 public key cryptography schemes in order to reach a pragmatic key 572 management mechanism for 6lowpans. 574 The trusted-server scheme relies solely on the server for key 575 agreement between nodes, e.g., Kerberos. If the server is 576 compromised, the trust amongst nodes is severed. Such scheme is not 577 suitable for 6lowpan networks because there is usually no guarantee 578 of seamless communication with a trusted server at anytime. 580 The key agreement scheme is key pre-distribution, where key 581 information is distributed among all 6lowpan nodes prior to 582 deployment. If the network deployers were to know which nodes were 583 more likely to stay in the same neighborhood before deployment, keys 584 MAY be decided a priori. However, because of the randomness of the 585 deployment, knowing the set of neighbors deterministically might not 586 be feasible. Furthermore, the presence of intruder nodes right from 587 the network deployment and initiation time cannot be rejected 588 outright as implausible. Some schemes like network shared keying, 589 pair-wise keying, and group keying, have been defined as variants of 590 key distribution. On-site key management mechanisms, while 591 warranting the same level of security as key pre-distribution schemes 592 have an obvious edge to cope up with network dynamics. 594 This class of key management scheme depends on asymmetric 595 cryptography, such as public key certificates that are irreversible 596 singularly. This irreversibility comes at a price-often staked by 597 the limited computation and energy resources of 6lowpan nodes. 598 However, these are the hardest cryptanalyze. Some of the most 599 popular examples include, but are not limited to Diffie-Hellman key 600 agreement, RSA or ECC [RFC2631]. Recent works on ECC implementation 601 for low power devices has proven its feasibility for sensor networks. 602 ECC provides security with smaller key size that is comparable to 603 security provided by RSA or AES with much higher key size. 605 Network topologies for 6LowPan (i.e., star and mesh) and presence of 606 FFD and RFD makes cluster based dynamic key management schemes seem 607 the most appropriate. These schemes use Master Keys; Network Keys 608 and Links keys which could be pre-installed for first round and can 609 be distributed by key transport mechanism during later rounds. This 610 scheme provides ease in key distribution and key revocation [ZigBee]. 612 10.2. Issues With Key Management in 6Lowpan 614 - In a 6lowpan, a malicious node MAY sit amongst other nodes at the 615 deployment phase-a problem of secure key assignment at bootstrap 616 time. 618 - A node is compromised during the operating time of 6lowpan-A key 619 revocation system MUST be employed. 621 - In a sleep-mode enabled 6lowpan, keys to sleeping nodes MUST be 622 deprived and reinstated after such nodes resume active state. 624 - In case the keys are compromised, a mechanism to diagnose security 625 violation MUST be invoked. 627 - It SHOULD allow and support dynamic addition of a new node. 629 11. Security Consideration in Bootstrapping a 6lowpan Node 631 This section aims to discuss how does a node configures itself 632 securely with a IPv6 router in the network. It involves assignment 633 of IPv6 prefix and the default IPv6 router in the 6lowpan. Further 634 details will be collaborated with 6lowpan commissioning/bootstrapping 635 works in near future according to the 6lowpan working group 636 rechartering. 638 12. Possible Scenarios Using Different Levels of Security 640 This section may suggest example scenarios with example solutions in 641 different cases (IPsec, SSL, other type of solutions) although this 642 document does not recommend or specify any security solutions. 643 Further details will be collaborated with 6lowpan architecture works 644 in near future according to the 6lowpan working group re-chartering. 646 13. Security Considerations 648 This document addresses only security issues around IPv6 over Low 649 Power WPAN. 651 14. IANA Considerations 653 There is no IANA considerations. 655 15. Acknowledgements 657 Thanks to Myungjong Lee at CUNY, USA, Rabia Iqbal, Mustafa Hasan and 658 Ali Hammad Akbar all at Ajou University for their valuable comments 659 to improve the document. Special thanks to Jung-Hyun Oh for his 660 valuable help on this document. 662 16. No I-D References 664 All references shown in this section MUST be added into the 665 Informative References before publishing it officially. 667 [ieee802.15.4] IEEE Std., 802.15.4-2003, ISBN 0-7381-3677-5, May 668 2003. 670 [802.15.4-ACM] Sastry, N. and Wagner, D., Security Considerations for 671 IEEE 802.15.4 Networks, ACM WiSE'04, October 2004. 673 [Madden] Madden, S. R., Franklin, M. J., Hellerstein, J. M., and 674 Hong, W., "TAG: a Tiny AGgregation service for ad-hoc sensor 675 networks". In Proceedings of the 5th Annual Symposium on Operating 676 Systems Design and Implementation, 2002. 678 [Stajano] Stajano, F., and Anderson, R., "The Resurrecting Duckling: 679 Security Issues for Ubiquitous Computing". In IEEE Computer Journal, 680 Volume 42, Issue 5, 2002. 682 [WSN] Shi, E., and Perrig, A., "Designing Secure Sensor Networks", In 683 IEEE Wireless Communications, December 2004. 685 [MAC802154] Misic V. B., Fung J., and Misic, J., "MAC Layer Security 686 of 802.15.4-Compliant Networks". In MASS 2005 Workshop, IEEE WSN 687 Conference. 689 [SEC802154] Xiao, Y., Sethi, S., Chen, H. H., and Sun B., "Security 690 Services and Enhancements in the IEEE 802.15.4 Wireless Sensor 691 Networks". In IEEE GlobeCom 2005. 693 [SECWSN] Chen, X., Makki, K., Yen, K., and Pissinou, N., "Sensor 694 Network Security: A Survey". In IEEE Communications Surveys & 695 Tutorials, Volume 11, No. 2, 2nd Quarter 2009. 697 [ZigBee] Specification Version 1.0, December 2004. 699 17. References 701 17.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, March 1997. 706 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 707 and M. Carney, "Dynamic Host Configuration Protocol for 708 IPv6 (DHCPv6)", RFC 3315, July 2003. 710 17.2. Informative References 712 [I-D.ietf-6lowpan-nd] 713 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 714 Discovery Optimization for Low-power and Lossy Networks", 715 draft-ietf-6lowpan-nd-15 (work in progress), 716 December 2010. 718 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 719 RFC 2631, June 1999. 721 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 722 Discovery (ND) Trust Models and Threats", RFC 3756, 723 May 2004. 725 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 726 Neighbor Discovery (SEND)", RFC 3971, March 2005. 728 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 729 RFC 3972, March 2005. 731 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 732 Internet Protocol", RFC 4301, December 2005. 734 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 735 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 736 September 2007. 738 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 739 over Low-Power Wireless Personal Area Networks (6LoWPANs): 740 Overview, Assumptions, Problem Statement, and Goals", 741 RFC 4919, August 2007. 743 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 744 "Internet Key Exchange Protocol Version 2 (IKEv2)", 745 RFC 5996, September 2010. 747 Authors' Addresses 749 Soohong Daniel Park 750 System Solution Laboratory, Samsung Electronics 751 416 Maetan-3dong, Yeongtong-gu 752 Suwon-si, Gyeonggi-do 442-742 753 KOREA 755 Phone: +82 31 200 4635 756 Email: soohong.park@samsung.com 758 Ki-Hyung Kim 759 Ajou University 760 San 5 Wonchun-dong, Yeongtong-gu 761 Suwon-si, Gyeonggi-do 442-749 762 KOREA 764 Phone: +82 31 219 2433 765 Email: kkim86@ajou.ac.kr 767 Wassim Michel Haddad 768 Ericsson 769 300 Holger Way 770 San Jose, CA 95134 771 US 773 Phone: +1 646 256 2030 774 Email: Wassim.Haddad@ericsson.com 776 Samita Chakrabarti 777 Ericsson 778 300 Holger Way 779 San Joe, CA 780 USA 782 Email: samita.chakrabarti@ericsson.com 784 Julien Laganier 785 Juniper 786 Sunnyvale, CA 787 USA 789 Email: Julien.ietf@laposte.net