Internet DRAFT - draft-zhao-aalsec-access
draft-zhao-aalsec-access
ROLL Wei-Cheng Zhao
Internet Draft De-Yun Gao
Expires: November 11, 2013 Hong-Ke Zhang
Wan-Ting Zhu
Beijing Jiaotong University
November 19, 2014
AAL security in Low Power and Lossy Networks
draft-zhao-aalsec-access-00
Abstract
Due to the seriously resource-constrained and easily attacked character
of Low Power and Lossy Networks-LNs, security becomes even harder to be
deployed. Here we present an AAL security scheme to protect devices in
AAL layer to help protect to communicate with each other safely including
a special key management, encryption, authentication and other security
measures.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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.
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
http://www.ietf.org/ietf/1id-abstracts.txt
-------The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 6, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in
effect on the date of publication of this document. Please review these
Zhao et al. Expires November 11, 2015 [Page 1]
Internet-Draft AAL security in LLNs November 19, 2014
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as described
in the Simplified BSD License.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as described in
the Simplified BSD License.
Table of contents
1. Introduction: ............................................... 2
2. Problem statement: .......................................... 3
3. The whole security scheme ................................... 3
4. Key management scheme ....................................... 5
5. summarize and expectation ................................... 7
6. References ................................................... 7
6.1. Normative References ...................................... 7
6.2. Informative References.... ................................ 8
Acknowledgment................................................... 8
1. Introduction:
LLNs
consist of low power devices which are seriously resource-constrained
in variety link quality condition. The low cost and limited power devices
can collect information like light intensity and transmit the data packets
though 802.15.4.Meanwhile, these devices can execute some control tasks
using typical sensor chip. Due to the situation that LLNs devices are
usually deployed at harsh outdoor environment where people can hardly get
into, LLNs are self-organized.
In this document, we discuss about LLN devices running IPv6 stack. We
firstly briefly introduce 6LoWPAN protocol below. 6LoWPAN is a protocol
aimed
at
importing
IPv6 in LLNs. It compresses IP and transport layer header
(only UDP at present) and fragments packets which are too large for lower
layer transmission to realize above function. And AAL is a layer between
network layer and data link layer using 6LoWPAN protocol.
In this document, a distributed AAL security scheme for LLNs is proposed.
We put forward the key management scheme calling network routing protocol
RPL. And encryption as well as authentication is carrying on using the
key. AAL security scheme accomplish the safely communication using as few
resource as possible.
Zhao et al. Expires November 11, 2015 [Page 2]
Internet-Draft AAL security in LLNs November 19, 2014
2. Problem statement:
Due to the transmission method of wireless broadcast, LLNs is naturally
vulnerable. While, these low power devices are severely
resource-constrained which lead to the lack of computing power as well
as the memory capacity. Regular security mechanisms and frameworks are
too complex and not suitable for LLNs.
3. The whole security scheme
To guarantee communication safety between sensor nodes, security methods
are needed in LLNS. However, complicated security protocol can't be
executed due to the serious resource-limited characteristic of the sensor
nodes. Thus in the document we propose and imple a new security scheme
ensuring normal interaction between sensor nodes and being light-weighted.
As is mentioned in the introduction, 6LoWPAN is used to compress packets
as well as deal with large packets.
+-----------------------------------------------------------------------------+
| Application |
+-----------------------------------------------------------------------------+
| RPL + key rotation |
+-----------------------------------------------------------------------------+
| uIP |
+-----------------------------------------------------------------------------+
| 6LoWPAN Header compression |
+-----------------------------------------------------------------------------+
| Security |
+-----------------------------------------------------------------------------+
| fragmentation |
+-----------------------------------------------------------------------------+
| 802.15.4 |
+----------------------------------------------------------------------------+
Figure1 System structure
The security scheme includes key-management, authentication, encryption
and other safety measures. During sending, packets delivered from 6LoWPAN
protocol are processed by the security scheme.
Zhao et al. Expires November 11, 2015 [Page 3]
Internet-Draft AAL security in LLNs November 19, 2014
+-----------------------------------------------------------------------------+
| compressed header | transport layer header | data |
+-----------------------------------------------------------------------------+
Figure 2 Packet Format
+-----------------------------------------------------------------------------+
|IF_SECURE| FRAG | ENCRPT |AUTH| RESERVE |
+-----------------------------------------------------------------------------+
0 1 2 3 4 7
Figure 3: Security Byte Format
Firstly, the packets are analyzed about packet type. We can analyze
specific security byte in the compressed header. The first bit(IF_SECURE)
stands for whether this packet goes though the security procedure.
IF_SECURE=0 means no security needed, IF_SECURE=1 means security scheme
deployed by the following bits. FRAG bit stands for whether this packet
is fragmented FRAG=0 means this packet is normally complete while FRAG=1
means this packet is fragment packet and needs special process. ENCRPT
bit stands for whether this packet should be encrypt. IF_SECURE=1 and
ENCRPT=0 means no need to encrypt this packet, IF_SECURE=1 and ENCRPT=1
means we should encrypt current packet. AUTH bit stands for whether this
packet should be authenticate. IF_SECURE=1 and AUTH=0 means no need to
authenticate this packet, IF_SECURE=1 and AUTH=1 means we should
authenticate current packet. The rest bits are reserved and default value
is 0.
+-----------------------------------------------------------------------------+
| key management |
+-----------------------------------------------------------------------------+
| authentication | encryption | anti-replay |
+-----------------------------------------------------------------------------+
Figure 4: Security Layer
If the packet is found to be a fragmented one, we need to take special
action before security goes forward. That is because we deployed security
scheme after 6LoWPAN, while 6LoWPAN detect maximum transmission unit in
link layer and extra secure bits are added during secure handle. In this
paper we get to a solution by move the fragment process part of 6LoWPAN
protocol from the top of the secure scheme to the bottom of it. Detailedly,
the packet firstly goes though 6LoWPAN without detect of the max length
and fragment after secure processes (including encryption and
authentication) and process this step after all security movement ends.
That is to say, when the packet is too long to transfer, we wait until
Zhao et al. Expires November 11, 2015 [Page 4]
Internet-Draft AAL security in LLNs November 19, 2014
every step of security accomplish to decide whether this whole packet needs
to fragment.
If the packet is found to be a DIO packet (detailedly introduce below),
step into the key rotating part.
Next(no matter what kinds of packet it is), authentication and encryption
parts get key from key management part(if needed in security byte
format).Key would be calling from the memory of device and encryption and
authentication would be applied. In most of the device, radio frequency
or CPU chip may provide encryption and authentication algorithm. To reduce
consumption of the resource serious device, hardware algorithm is a great
way to complete the complex computing. Specifically, only the load
(including the uncompressed transport layer header) is encrypted and the
whole packet is authenticated. That's because if we encrypt the header
we need to add a new header and make the packet much longer, while
authentication part doesn't get that problem.
Finally, the sequence number is added and the new secure packet is
transferred to lower layer to send. That is when we decide whether this
packet is too long and needs fragment. Receiving process is similar as
sending process including decryption, authentication, key management and
fragmentation.
4. Key management scheme
Traditional key management schemes are usually based on public key
encryption, which is difficult even impossible for LLNs to imply. However,
LLNs are more likely to sustain Eavesdropping attack due to Wireless
Broadcast Advantage of the LLNs devices. While traditional embedded key
management schemes usually use key pool approach which spends a lot of
memory to save keys and geographical position message is needed if we want
an advanced topology. Thus, a new efficient key management scheme is badly
needed. In this document, we propose a key management scheme based on LLNs
routing protocol RPL.
To start with, we introduce normal network method of LLNs applying RPL.
The root device broadcast DIO(a routing passage including link quality
message called rank ) to invite other devices nearby to join in its DODAG.
These devices get the passage and decide to join in by a parameter called
rank, and so on. This project continues until all the devices join in the
topology. In this document, security methods like authentication and
encryption are added though all the procedure and rotating happened during
DIO accept.
Firstly, a global public key is assigned to all devices for sequential
authentication. Then, first-round authentication happened to routing
packets DIO during networking period using previous public key. Packets
that pass the authentication will help their senders join the DODAG and
Zhao et al. Expires November 11, 2015 [Page 5]
Internet-Draft AAL security in LLNs November 19, 2014
lead to the first-round rotating. Child devices analyze DIO and generate
first-round encryption key by extracting rank, DODAG number as well as
father device ID as original data and encrypting this data by previous
key. DAO(response of DIO)including round number to identify key rotating
complete in its expand option is send after all above complete. Then both
child device and father device can delete the previous key (while father device
need to wait for each child giving successful response). Thereafter every DIO
lead to a new round key.
DIO is a route control packet whose transmission frequency depends on
network stability. Rotating caused by DIO connect security together with
link state, which improve security efficiency a lot. What is more, rank
of different devices are differ from each other as well as device ID, which
lead to the phenomenon that devices of different father devices use various
round key while these of the same father device share the same key. So
that the whole network use different round key to protect the devices from
password cracking while every single device only need to save two keys(the
key to communication with the father device and the key to communicate
with child devices).
Assume there are several LLNs devices deployed in the open-round. Root
device is very close to device A. Then the interaction diagram below shows
the detail process of how the devices join in the DODAG and how they manage
to rotate.
root A B C
| | | |
|-------DIOr0---------->| | |
| | | |
|<------DAOr0-----------| | |
| | | |
| |--------DIOa0 ---------->| |
| | | |
| |<-------DAOa0 -----------| |
| | | |
| | |<-------DISc0----------- |
| | | |
| | |--------DIOb0----------> |
| | | |
| | |<-------DAOb0------------|
| | | |
....................................
After n rounds
....................................
| | | |
|<----- DIOrn ----------| | |
Zhao et al. Expires November 11, 2015 [Page 6]
Internet-Draft AAL security in LLNs November 19, 2014
|<------DAOrn ----------| | |
| | | |
| |-------DIOan ----------->| |
| | | |
| |<------DAOan ------------| |
| | | |
| | |<------DIScn-------------|
| | | |
| | |-------DIObn------------>|
| | | |
| | |<------DAObn-------------|
Figure 5: Interaction Diagram
5. summarize and expectation
We put forward a complete AAL security scheme above, especially focus on
the key management realizition.By using meaningful syliable in broadcast
DIO, we sucessfully carry on key distribution and rotating without using
extra link consume and internal memory.The keys are different in the whole
network while devices holding the same father device share the same device.
LLNs devices can apply this security scheme to complete safty communication.
While, this scheme is only suitable for the LLNs based on Ipv6 and deploying
RPL routing protocol.What's more, adding new devices to the previous LLNs
could cause great risk if the safty of this new one can not be detected.This
shortage should be solved in next vision by adding intrusion Detection
mechanism.We may also add application layer security and link layer
security in next verion.
This document does not specify any security considerations.
6. References
6.1. Normative References
[RFC6550] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis,
K. Pister, R. Struik, JP. Vasseur, and R. Alexander, "RPL:
IPv6 Routing Protocol for Low-Power and Lossy Networks",
RFC6550, March 2012.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC6552] P.Thubert, "RPL Objective Function 0", RFC6552, March 2012.
Zhao et al. Expires November 11, 2015 [Page 7]
Internet-Draft AAL security in LLNs November 19, 2014
[RFC6206] P.Levis, T.Clausen, J.Hui, O.Gnawali, and J.Ko, "The Trickle
Algorithm", RFC6206, March 2011.
6.2. Informative References
Jennifer Yick. Wireless sensor network survey[J]. Computer
networks,2008,52(12): 2292-2330.
Holzmann G J. The SPIN Model Checker, Primer and Reference Manual.
Addison-Wesley, 2003.
POTTIE G J, KAISER W J. Wireless Integrated Network Sensors[J].
Communications of the ACM (S0001-0782), 2000, 43(5) : 551-558.
Oscar Delgado-Mohatar, Amparo Futer-Sabater, Jose M.Sierra.
Alight-weight authentication scheme for wireless sensor networks. Ad Hoc
Networks 9(2011)727-35.
Javier Lopez, Rodrigo Roman, Isaac Agudo, Carmen Fernandez-Gago. Trust
management systems for wireless sensor networks: Best practices. Computer
Communications 33(2010)1086?093.
Su Zhong, Lin Chuang, Feng fujun, Ren Fengyuan. Key Management Schemes
and Protocols for Wireless Sensor Networks. Journal of Software,
V01.18,No.5,May 2007,PP.1218-1231.
Authors' Addresses
Wei-Cheng Zhao, De-Yun Gao, Hong-Ke Zhang, Yan-fei Ma, Wan-Ting Zhu,
National Engineering Lab for NGI Interconnection Devices
Beijing Jiaotong University, China
Phone: +8613521693762
Email: 11111018@bjtu.edu.cn
gaody@bjtu.edu.cn
hkzhang@bjtu.edu.cn
11111019@bjtu.edu.cn
Acknowledgment
This work was supported by the National Major Projects of China
(Grant No. 2012ZX03005003).
Zhao et al. Expires November 11, 2015 [Page 8]
