wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

6LoWPAN: IP for Wireless Sensor Networks and Smart Cooperating Objects 51-13
active RFC4944 of the 6LoWPAN working group. It should be mentioned here that active discussions
in the time of writing this chapter of 6LoWPAN working group are heading to an update of RFC4944.
Hence, the values might differ if the RFC is updated but might provide an overview about approximate
header sizes. The third column in the table shows the remaining space for the payload or further protocol
headers. The combination of MESH, FRAG, and IP headers with the listed TCP, UDP, and ICMP
headers is omitted for clarity.
51.5.8 Security
Specific application domains and scenarios require secure data transmission and data integrity. For
example, for health care applications, recorded vital parameters of patients sent via 6LoWPAN over
IEEE 802.15.4 should be exchanged with trusted endpoints only. The 6LoWPAN working group analyzed
different possibilities to meet the necessary security constraints.
The first security issue that has to be considered is the secure data transmission itself. IEEE 802.15.4
provides AES encryption security on the link layers for secure point-to-point communication. System
engineers should always keep in mind that it is not specified in IEEE 802.15.4, how the key for the
encryption is deployed. The 6LoWPAN working group proposes to use the built-in AES security for
communication of RFDs in terms of IEEE 802.15.4.
6LoWPAN does not exclude the usage of existing security mechanisms and protocols like IPsec and
TLS, which allow end-to-end security. Because of the estimated higher energy consumption due to the
security on IP layer or above, these security mechanisms are proposed to be used by FFDs only. FFDs
are expected to have lower constraints concerning energy consumption. Protocols like IPsec and TLS
permit interoperability with external IP-based networks also (cf. Figure 51.9).
The second security issue bases on the method how IPv6-compliant addresses are derived from the
802.15.4 built-in EUI-64 bit device identifier. Hence, this identifier should be unique for every 802.15.4
device, the generated IP addresses are unique as well and might be traced by attackers. There is no protection
that the generated IPv6 address is not globally unique. In specific scenarios, persons do not want
to be identified through their surrounding wireless body area network based on 6LoWPAN devices.
Thus, the 6LoWPAN specifications do not forbid the usage of customizable device identifiers for IPv6
address generating.
External IP core
6LoWPAN FFD
network node edge router
FFD 6LoWPAN node RFD 6LoWPAN node
Application
Application
Application
Application
TCP/UDP
TCP/UDP
TCP/UDP
TCP/UDP
IPv6
6LoWPAN/IPv6
6LoWPAN
6LoWPAN
802.X MAC 802.X + 802.15.4 MAC
802.15.4 MAC
802.15.4 MAC
802.X PHY 802.x + 802.15.4 PHY 802.15.4 PHY 802.15.4 PHY
Point-to-point via 802.15.4 AES End-to-end via IPSec End-to-end via TLS
FIGURE 51.9
Security protocols.
© 2011 by Taylor and Francis Group, LLC