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

               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-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 June 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.


   This document describes IPv6 over Low Power WPAN security analysis.

Daniel Park, et al.       Expires June 6, 2006                  [Page 1]

Internet-Draft         6LoWPAN Security Analysis           December 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   5.  Assumption . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  6lowpan security analysis  . . . . . . . . . . . . . . . . . .  4
     6.1   IEEE 802.15.4 Security analysis  . . . . . . . . . . . . .  5
     6.2   IP Security analysis . . . . . . . . . . . . . . . . . . .  6
   7.  6lowpan trust models . . . . . . . . . . . . . . . . . . . . .  6
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  7
   11.   No I-D References  . . . . . . . . . . . . . . . . . . . . .  7
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . .  7
   12.1  Normative References . . . . . . . . . . . . . . . . . . . .  7
   12.2  Informative References . . . . . . . . . . . . . . . . . . .  7
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9

Daniel Park, et al.       Expires June 6, 2006                  [Page 2]

Internet-Draft         6LoWPAN Security Analysis           December 2005

1.  Introduction

   6lowpan (IPv6 over Low Power WPAN) was formed as a IETF working group
   newly this year.  The principal object of the 6lowpan working group
   is to newly design IPv6 transmission over IEEE 802.15.4
   [ieee802.15.4] networks.

   In occation, IEEE 802.15.4 applications do not require at least
   strict security models.  However, many of application are security

   Specifically, some of the IEEE 802.15.4 optional features actually
   reduce security and implementation would be limited for their

   To improve security for IEEE 802.15.4, many efforts are in the
   progress of proposing several change  and adding new schemes to the
   IEEE 802.15.4 specification.  But almost approaches are certain to
   target for link layer security improvement not any upper layers even
   though IPv6 enhanced security is able to be applied to 6lowpan.

   This document tries to analyze what security threats are feasible
   during the deployment of 6lowpan and discuss 6lowpan trust model
   using both link layer and IP layer security packages if necessary.

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
   power, low cost, large number of devices, etc.  The security aspect,
   however, seems a bit tradeoff element in the 6lowpan since security
   is always a costly function, and this is particular true to low rate
   WPAN.  Obviously, adding security makes the issue even more
   challenging.  For instance, when putting IPv6 on top of 6lowpan, it
   would be better to use IP security and turn off the security of WPAN
   since the security architecture defined by IEEE 802.15.4 seems

Daniel Park, et al.       Expires June 6, 2006                  [Page 3]

Internet-Draft         6LoWPAN Security Analysis           December 2005

   somewhat loose and more work needs to be done today.  But on the
   other hand, IP security is relatively mature for services at IP or
   other upper layers.

   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

   Further study in the next version.

5.  Assumption

   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.

6.  6lowpan security analysis

   In this section, both IEEE 802.15.4 MAC security and IP security are
   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.

Daniel Park, et al.       Expires June 6, 2006                  [Page 4]

Internet-Draft         6LoWPAN Security Analysis           December 2005

6.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 entryption, 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.

   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.

Daniel Park, et al.       Expires June 6, 2006                  [Page 5]

Internet-Draft         6LoWPAN Security Analysis           December 2005

6.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.) in which increase the packet size

   Further study in the next version.

7.  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.

   Further study in the next version.

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

Internet-Draft         6LoWPAN Security Analysis           December 2005

8.  Security Considerations

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

9.  IANA Considerations

   There is no IANA considerations.

10.  Acknowledgements

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

11.  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.

12.  References

12.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.

12.2  Informative References

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

   [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)",

Daniel Park, et al.       Expires June 6, 2006                  [Page 7]

Internet-Draft         6LoWPAN Security Analysis           December 2005

              RFC 3972, March 2005.

Authors' Addresses

   Soohong Daniel Park
   Mobile Platform Laboratory, SAMSUNG Electronics.


   Ki-Hyung Kim
   Ajou University


   Eunil Seo
   Samsung AIT


Daniel Park, et al.       Expires June 6, 2006                  [Page 8]

Internet-Draft         6LoWPAN Security Analysis           December 2005

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 (2005).  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 June 6, 2006                  [Page 9]