[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

Network Working Group                                     S. Daniel Park
Internet-Draft                                       SAMSUNG Electronics
Expires: December 24, 2006                                        K. Kim
                                                         Ajou University
                                                                  E. Seo
                                                             Samsung AIT
                                                          S. Chakrabarti
                                                           June 22, 2006

               IPv6 over Low Power WPAN Security Analysis

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on December 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document discusses possible threats and security options for
   IPv6-over-IEEE802.15.4 networks.  It is an informational document to
   raise awareness of security issues in IPv6 lowPan networks.

Daniel Park, et al.     Expires December 24, 2006               [Page 1]

Internet-Draft          6LoWPAN Security Analysis              June 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Security Threats . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   7.  6lowpan security analysis  . . . . . . . . . . . . . . . . . .  5
     7.1.  IEEE 802.15.4 Security analysis  . . . . . . . . . . . . .  6
     7.2.  IP Security analysis . . . . . . . . . . . . . . . . . . .  7
   8.  Key Management in 6lowpan  . . . . . . . . . . . . . . . . . .  7
     8.1.  Existing Key management methods  . . . . . . . . . . . . .  8
     8.2.  Issues with Key management in 6lowpan  . . . . . . . . . .  8
   9.  Security consideration in bootstrapping a 6lowpan node . . . .  8
   10. Possible scenarios using different levels of security  . . . .  8
   11. 6lowpan trust models . . . . . . . . . . . . . . . . . . . . .  8
   12. Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   15. No I-D References  . . . . . . . . . . . . . . . . . . . . . .  9
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     16.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     16.2. Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Daniel Park, et al.     Expires December 24, 2006               [Page 2]

Internet-Draft          6LoWPAN Security Analysis              June 2006

1.  Introduction

   The principal object of the 6lowpan working group is to design IPv6
   transmission over IEEE 802.15.4 [ieee802.15.4] networks.

   IEEE 802.15.4 [ieee802.15.4] is designed to support variety of
   applications in personal area networks; many of applications are
   security sensitive.

   Specifically, some of the IEEE 802.15.4 optional features actually
   reduce security and implementation would be limited for their
   extensions.  The applications range from defense systems to building
   monitoring, fire-safety, patient monitoring etc.  If the network is
   not secured, an intruder can inject incorrect messages to trigger
   false situations.  Thus link-layer security is quite necessary in
   IEEE802.15.4 networks.

   IEEE 802.15.4 is working on improving the link-layer security
   specification.  However, this document will focus on discussing
   different security threats from the 6lowpan perspective and discuss
   different options of applying existing security methods to overcome
   those threats.  The goal is to provide a trust model using both link-
   layer and IP layer security packages, if possible.

   Designing a new security protocol for 6lowpan network is out of scope
   of this document.  However, it may state desired security
   requirements which can be fed to the appropriate IETF security
   working group in order to suggest appropriate security protocols.

2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Terminology

   This document uses terminology specific to IPv6 and DHCPv6 as defined
   in "Terminology" section of the DHCPv6 specification [RFC3315].

4.  Overview

   As described in [I-D.ietf-6lowpan-problem], 6lowpan has some of the
   characteristics against existing IP networks such as small packet
   size, low bandwidth of IEEE 802.15.4 standard [ieee802.15.4], low

Daniel Park, et al.     Expires December 24, 2006               [Page 3]

Internet-Draft          6LoWPAN Security Analysis              June 2006

   power, low cost, large number of devices, etc.  The security aspect,
   however, seems a bit tradeoff in the 6lowpan since security is always
   a costly function.  This is particularly true to low rate WPAN.
   Obviously, adding security makes the issue even more challenging.
   For instance, when putting IPv6 on top of 6lowpan, it seems one could
   use IP security and turn off the security of WPAN since the security
   architecture defined by IEEE 802.15.4.  But on the other hand, IP
   security is relatively mature for services at IP or other upper

   But of course, it is a question whether those 6lowpan devices can
   support IP security as it is. for low layer services, for example MAC
   sublayer association, beaconing, orphanning, etc.  WPAN security must
   be used since IP security is not supposed to take care of lower

   Security Considerations paper[ 802.15.4-ACM] outlines that
   IEEE802.15.4 link-layer provides access control, message integrity,
   message confidentiality and replay-protection services.  Yet the
   document is not clear about key management methods, state of ACL
   table in the event of power loss and support of group keying.
   Network shared common key may be an answer for link-layer security in
   this case, but that is vulnerable with replay attacks and with stolen
   devices.  However, in most common cases, network shared keying may be
   the simple answer to the security at the link-layer for the power-
   deprived, reduced function-devices, as it is easily configurable
   among hundreds of devices.

   IPSec is mandatory to run IPv6, but considering power constraints and
   limited processing capability of the IEEE802.15.4 capable devices
   IPSec may be compute intensive; IKE messaging will not work well in
   LowPower networks as we want to reduce signaling in this network.
   Thus 6lowpan may need to define its own keying methods that require
   minimum overhead in packet-size and ofcourse number of signaling
   messages.  IP-layer security will provide authentication and
   confidentiality between end-nodes and across multiple lowpan-links.
   This document later discusses applicability of IP-layer security in
   the case of 6lowpan network usage and applications.  It may be useful
   only when two nodes want to send/receive all messages securely.
   However, in most cases, the security may be requested at the
   application layer as needed, while other messages can flow in the
   network without security overhead.

   The possible threats in this type of network are intrusion, sink-hole
   and replay attacks.  A third party entity can inject bad routes in
   the network, act as a default router attracting all the packets to
   itself, or it can snoop packets and then launch replay attacks on the
   6lowpan nodes.  These attacks can cause harm especially when the

Daniel Park, et al.     Expires December 24, 2006               [Page 4]

Internet-Draft          6LoWPAN Security Analysis              June 2006

   attacker is a high-power device, such as a laptop.  It can easily
   drain batteries of the 6lowpan devices by sending broadcast messages,
   redirecting routes etc.

   A possible solution to security issues in the 6lowpan network might
   be application level security (for example, SSL) on top of link-layer
   security.  Link-layer security protects from intrusion in the link
   and the application-level security protects from another user peeking
   at the data and impersonation.

   Further study in the next version.

5.  Security Threats


6.  Assumptions

   The [I-D.ietf-6lowpan-problem] describes two security concerns as

   In Section 4.6 Security: Although IEEE 802.15.4 provides AES link
   layer security, a complete end-to-end security is needed.

   In Section 5 Goals: Security threats at different layers must be
   clearly understood and documented.  Bootstrapping of devices into a
   secure network could also be considered given the location, limited
   display, high density and ad hoc deployment of devices.

   This document will try to meet the above considerations.

   In addition, existing IP security technologies will be simplified to
   be implemented on the 6lowpan small devices. 6lowpan security
   architecture will shed off lots of fat from IP security technologies
   whenever available.

   IEEE 802.15.4 AES (Advanced Encryption Standard) will be used for
   6lowpan security architecture in conjunction with IP security
   whenever available.

   Further study in the next version.

7.  6lowpan security analysis

   In this section, both IEEE 802.15.4 MAC security and IP security are

Daniel Park, et al.     Expires December 24, 2006               [Page 5]

Internet-Draft          6LoWPAN Security Analysis              June 2006

   tackled to search for a new 6lowpan trust models and available
   solution spaces if feasible.  The principal object of these analysis
   is to improve 6lowpan security level as we use IP layer security
   mechanism as possible regardless of 802.15.4 vulnerable MAC security.
   802.15.4 MAC enhancement and amendment are not scope of this document
   but IEEE 802 standard stuff.

7.1.  IEEE 802.15.4 Security analysis

   The MAC of IEEE 802.15.4 provides security services that are
   controlled by the MAC PIB (PAN Information Base).  For security
   purpose, the MAC sublayer maintains an access control list (ACL) in
   its MAC PIB.  By specifying a security suite in the ACL for a
   communication peer, a device can indicate what level security should
   be used (i.e., none, access control, data encryption, frame
   integrity, etc.) for communications with that peer.  In addition, MAC
   sublayer offers a secured mode and an unsecured mode.

   A critical function of IEEE 802.15.4 MAC is frame security.  Frame
   security is actually a set of optional services that may be provided
   by the MAC to the upper layers (applications).  The standard strikes
   a balance between the need for these services in many applications,
   and the desire to minimize the burden of their implementation on
   those applications that do not need them.  As described in [802.15.4-
   ACM], if an application does not set any security parameters, then
   security is not enabled by default.  The [ieee802.15.4] defines four
   packet types: beacon packets, data packets, acknowledgements packets
   and control packets for the media access control layer.  It does not
   support security for acknowledgement packets.  But on the other hand,
   other packet types can optionally support integrity protection and
   confidentiality protection for the packet's data field.

   Due to the variety of applications targeted by IEEE 802.15.4, the
   processes of authentication and key exchange are not defined in the
   standard.  Devices without the key cannot decrypt the encryped

   In addition, unsecured mode is suitable for some applications in
   which implementation cost is important, and security is either not
   required or obtained in other ways.  In this case, 802.15.4 node is
   very vulnerable.

   The security service enables the MAC to select the devices with which
   it is willing to communicate.  The device may decide to communicate
   with some devices, and not others.  To minimize complexity, the
   access control service is performed on an individual device basis,
   rather than on groups or collections of devices.

Daniel Park, et al.     Expires December 24, 2006               [Page 6]

Internet-Draft          6LoWPAN Security Analysis              June 2006

   Unlike file transfer or voice communication applications common with
   other protocols, IEEE 802.15.4 applications often transmit messages
   that do not convey secret information.

   Further study in the next version.

7.2.  IP Security analysis

   IPsec (IP security protocol) provides per-packet authenticity and
   confidentiality guarantees between peers communicate using IPsec.  It
   is available for both IPv4 and IPv6.

   Basically, IPsec targets to general IP nodes operated over ethernet.
   It means each node has some of fluent stack size, bandwidth and non-
   low cost limitations like 6lowpan.

   Given the IPsec background, it is at least not suitable for 6lowpan
   nodes.  Especially, 6lowpan node may not be able to operate all IPsec
   algorithms on its own capability either FFD or RFD.

   Bandwidth is very sensitive element in the 6lowpan, but IPsec
   generates some of redundant packets such as AH/ESP header.

   IPsec needs shared secret key between nodes called IKE (Internet Key
   Exchange), and it will make the key exchange in secrecy possible.  It
   can, however cause some of redundant packets over the 6lowpan

   if NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND
   (Secure Neighbor Discovery) should at least considered to provide
   security in conjunction with neighbor discovery protocol.  So far,
   CGA (Cryptographically Generated Addresses) [RFC3972] and SeND
   options [RFC3971] are newly designed by IETF and it works well over
   existing IP networks.  However, CGA seems very complex to be applied
   to 6lowpan networks.  Furthermore, SeND options requires huge
   additional options (i.e., CGA option, RSA Signature option, Timestamp
   and Nonce option and etc.) which increase the packet size
   accordingly.  Thus it is doubtful if Secure Neighbor Discovery
   protocol could be directly applicable to 6lowpan networks without any

   Further study in the next version.

8.  Key Management in 6lowpan


Daniel Park, et al.     Expires December 24, 2006               [Page 7]

Internet-Draft          6LoWPAN Security Analysis              June 2006

8.1.  Existing Key management methods


8.2.  Issues with Key management in 6lowpan


9.  Security consideration in bootstrapping a 6lowpan node

   This section should discuss how does a node configures itself
   securely with a IPv6 router in the network.  It involves assignment
   of IPv6 prefix and the default IPv6 router in the 6lowpan.

10.  Possible scenarios using different levels of security

   This section may suggest example scenarios with example solutions in
   different cases (IPSec, SSL, other type of Solutions) although this
   document does not recommend or specify any security solutions.

11.  6lowpan trust models

   To meet the security requirement of 6lowpan, a new trust models
   including new IPsec hashing algorithms, new key exchange schemes,

   6lowpan bootstraping should be at least considered as one of 6lowpan
   trust models.

   Since this document does not provide any particular solution, further
   specific mentions should be aligned with WG consensus.

12.  Security Considerations

   This document addresses only security issues around IPv6 over Low
   Power WPAN.

13.  IANA Considerations

   There is no IANA considerations.

Daniel Park, et al.     Expires December 24, 2006               [Page 8]

Internet-Draft          6LoWPAN Security Analysis              June 2006

14.  Acknowledgements

   Thanks to Myungjong Lee of CUNY for his valuable comments on this

15.  No I-D References

   All references shown in this section MUST be added into the
   Informative References before publishing it officially.

   [ieee802.15.4] IEEE Std., 802.15.4-2003, ISBN 0-7381-3677-5, May

   [802.15.4-ACM] Sastry, N. and Wagner, D., Security Considerations for
   IEEE 802.15.4 Networks, ACM WiSE'04, October 2004.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

16.2.  Informative References

              Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
              Assumptions, Problem Statement and Goals",
              draft-ietf-6lowpan-problem-02 (work in progress),
              February 2006.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

Daniel Park, et al.     Expires December 24, 2006               [Page 9]

Internet-Draft          6LoWPAN Security Analysis              June 2006

Authors' Addresses

   Soohong Daniel Park
   Mobile Convergence Laboratory, SAMSUNG Electronics.

   Email: soohong.park@samsung.com

   Ki-Hyung Kim
   Ajou University

   Email: kkim86@ajou.ac.kr

   Eunil Seo
   Samsung AIT

   Email: eunil.seo@samsung.com

   Samita Chakrabarti

   Email: samitac2@gmail.com

Daniel Park, et al.     Expires December 24, 2006              [Page 10]

Internet-Draft          6LoWPAN Security Analysis              June 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Daniel Park, et al.     Expires December 24, 2006              [Page 11]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/