Internet DRAFT - draft-cansever-6lowpan-integration
draft-cansever-6lowpan-integration
6lowpan D. Cansever
Internet-Draft G. Mulligan
Intended status: Informational C. Williams
Expires: May 14, 2008 SI International
November 11, 2007
Integration of 6LoWPAN into IP networks
draft-cansever-6lowpan-integration-00.txt
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.
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 May 14, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The IETF 6LoWPAN working group was formed in 2004 to address the
challenge of enabling wireless IPv6 communication over the newly
standardized IEEE 802.15.4 low-power radio for devices with limited
space, power and memory, such as sensor nodes [3]. IEEE 802.15.4
radio links, coupled with the interoperability and ubiquity of IP,
will lead to exciting new deployment scenarios for these low-power
networks. Sensor wireless networks will be integrated into wired
Cansever, et al. Expires May 14, 2008 [Page 1]
Internet-Draft 6LoWPAN Integration November 2007
and/or wireless fixed infrastructure. The integration of these
sensor networks with the Internet and wireless infrastructure
networks increases the network capacity, coverage area and
application domains. In this draft we provide various integration
scenarios and discuss associated issues with such deployments.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usage of Network Mobility for Sensor networks . . . . . . . . . 4
4. Usage of SEND to protect provide security access during
change of the access network . . . . . . . . . . . . . . . . . 5
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Scurity Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Normative references . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Cansever, et al. Expires May 14, 2008 [Page 2]
Internet-Draft 6LoWPAN Integration November 2007
1. Introduction
In the future interconnection framework for wireless sensor 6LoWPAN
networks, internetworking will not necessarily be limited to a way to
transport information from and to remote hosts. The foreseen degree
of integration between sensor networks may reach upper levels of the
protocol stack, where one network may offer services to others
(including communication services). In such a setting, even 6LoWPAN
sensor network components may be heterogeneous, consisting of sensors
with varied functionalities, capabilities and interconnection
requirements. Currently, wireless sensor networks are beginning to
be deployed at an accelerated pace. It is not unreasonable to expect
that in the near future, many segments of the world will be covered
with wireless sensor networks that will be accessible via the
Internet. Integration of wireless sensor networks with wireless
local area networks and the Internet, while being important, comes
with connectivity and security issues. This draft is an attempt to
identify such issues, and to propose solutions towards their
resolution.
Sensor networks share several characteristics of ad-hoc scenarios in
that sensor nodes are capable of reciving and forwarding packets to
their peers. However, tiny sensor devices may have more stringent
processing power, memory and energy constraints than other types of
ad hoc networks. These constraints generally imply the need for a
hierarchical ad-hoc network structure in which low-tier sensor nodes
connect to the Internet via one or more levels of gateway devices.
In this draft, we assume that each autonomous network of wireless
sensor devices will have one gateway device. This gateway device is
responsible for media conversion (from 802.15.4 to another link layer
technology, such as 802.11, and vice versa) and for route advertising
to the outside world, which may be a wireless local area network
connected to the Internet.
There will be deployment scenarios where 6LoWPAN networks have
persistent connectivity to the outside world via its gateway device.
At the same time, there may be deployment scenarios that require that
a 6LoWPAN network change its point of attachment to the outside world
from an IP persepective. This may occur, for example, when a sensor
network is part of a moving vehicle which may roam from one wireless
local area network to another wireless local area network with
different IP network prefixes. By the same token, an autonomous
sensor network may be deployed in a location with no wireless (or
wired) local area networks. In this case, its connectivity to the
outside world, when it exists, will be intermittent. Also, the
intermittent connectivity to the Internet may have different
characteristics each time they occur. For example, connectivity of
the 6LoWPAN network to the internet may be realized via an agent
Cansever, et al. Expires May 14, 2008 [Page 3]
Internet-Draft 6LoWPAN Integration November 2007
(e.g., a vehicle) which features a satellite interface. At different
points in time, different agents may provide connectivity functions;
in which case the point of attachment of the sensor network may
correspond to a different IP address prefix. Note that the two
scenarios depicted above are equivalent from an IP connectivity point
of view. In the first scenario, the sensor networ moves from one
access network to another. In the second scenario, agents with
different IP addresses provide access functions to a stationary
sensor network. In either case, the IP address of the point of
attachment will change over time.
Here, the requirement is to provide global reachability to the
6LoWPAN nodes no matter where the correspondent peers are located,
and no matter what their point of attachment is. The 6LoWPAN nodes
must still be reachable with their orginally prescribed IPv6
addresses. This draft discusses these deployment scenarios and the
associated issues, and proposes solutions which may be used in such
deployments.
2. Terminology
See RFC3753 [1]for mobility terminology used in this document.
3. Usage of Network Mobility for Sensor networks
Mobility is a fundamental characteristic of a wireless network with
mobile users, and it is therefore anticipated that future networks
will provide mobility support as an integrated and ubiquitous
service. Mobility scenarios anticipated in future networks include
simple end-user migration from one subnetwork to another (as in
cellular or WLAN hot-spot services), as well as more complex mobility
patterns involving movement of radio routers and sensor network
clusters. Collections of sensor networks must be reachable as they
move across different wireless domains. Scalable and accurate
indirection schemes need to be devised to allow for this
functionality.
Mobile IPv6 network mobility (NEMO) [2] defines a process that
enables Mobile Networks to attach to different points in the
Internet. The protocol is an extension of Mobile IPv6 and allows
session continuity for every node in the Mobile Network as the
network moves. Use of NEMO will enable all 6LoWPAN nodes to be
accessible, no matter what the current point of attachment to the
wide area IP network is.
Cansever, et al. Expires May 14, 2008 [Page 4]
Internet-Draft 6LoWPAN Integration November 2007
Diagram of NEMO and 6lowpan integration is provided. [3] , e.g.,
(Nodes in the 6lowpan network)
* * * ... * * *
6lowpan
network
|
|
+-------------+
| NEMO Client |
+-------------+
|
|
+--------------------+
|Access Network (AR) |
+--------------------+
|
+-------------------+
| Internet |
+-------------------+
|
|
+---------------+
| Correspondent |
| Node |
+---------------+
Figure 1
The NEMO client integration enables the sensor application residing
on some correspondent node provides global reachability to the
6lowpan nodes even when the access network for the 6lowpan network
changes.
4. Usage of SEND to protect provide security access during change of
the access network
IPv6 nodes use the Neighbor Discovery protocol (ND) [4] to discover
other nodes on the link, to determine the link-layer addresses of
other nodes on the link, to find routers, and to maintain
reachability information about the paths to active neighbors. If
proper authentication mechanisms are not in place, straight use ND in
Cansever, et al. Expires May 14, 2008 [Page 5]
Internet-Draft 6LoWPAN Integration November 2007
sensor networks may introduce security vulnerabilities. The IETF has
created the Secure Neighbor Discovery Protocol (SeND) [5] to provide
authentication services for the ND. SeND may be used as a solution
between the NEMO client residing in the Sensor network and the access
network which will have a SeND service for providing authenticated
NEMO autoconfiguration. In this solution, NEMO with SeND may provide
a means by which the access network is properly authorized to connect
to the sensor network.
Diagram of NEMO, SEND and 6lowpan integration is provided. [5] ,
e.g.,
(Nodes in the 6lowpan network)
* * * ... * * *
6lowpan
network
|
|
+---------+
| NEMO & |
| SEND |
+---------+
|
|
+--------------------+
|Access Network (AR) |
| With SEND |
+--------------------+
|
+-------------------+
| Internet |
+-------------------+
|
|
+---------------+
| Correspondent |
| Node |
+---------------+
Figure 2
Authentication process specified in SeND may involve the use of
Cansever, et al. Expires May 14, 2008 [Page 6]
Internet-Draft 6LoWPAN Integration November 2007
server infrastructure for certificate management purposes. It may be
impractical to have a server infrastrucure in place for
authentication in the deployment scenarios discussed in this draft.
Therefore, the Cryptographically Generated Addresses (CGA) [6] option
of SeND may be a useful tool for 6LoWPAN networks in providing
authentication services.
5. Conclusion
6LoWPAN networks may be deployed remotely in non-traditional
scenarios. Access networks for these 6LoWPAN networks may be
intermittently available, and their IP address prefixes may change
over time. This means that the IP layer has new requirements to be
able to provide access to these 6LoWPAN networks via changing access
networks and to do so in a secure manner. The usage of SeND and NEMO
protocols allows 6LoWPAN networks to be fully integrated into a
dynamic mobile hetergenous network for ensuring global reachability
to the individual 6LoWPAN nodes.
6. Scurity Considerations
Remoteley deployed 6LoWPAN networks with changing points of
atatchments are subject to multiple security risks. In this draft we
addresse the issue of authentication using the SeND protocol. SeND
does not provide privacy. Privacy within the 6LoWPAN network is
provided by 802.15.4 encryption services. Privacy between the
6LoWPAN network point of attachment and the local area access network
may be established using IPsec. Future versions of this draft will
address security issues of 6LoWPAN deployment scenarios in more
detail.
7. Normative references
[1] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC 4944, September 2007.
[4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
Cansever, et al. Expires May 14, 2008 [Page 7]
Internet-Draft 6LoWPAN Integration November 2007
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[6] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
Authors' Addresses
Derya Cansever
SI International
12012 Sunset Hills Road, Suite 800
Reston, VA 20190
USA
Phone: 703.234.6960
Email: derya.cansever@si-intl.com
Geoff Mulligan
SI International
Consultant, Colarodo Springs, CO 80901
USA
Phone: 719.593.2992
Email: geoff@proto6.com
Carl Williams
SI International
Consultant, Palo Alto, CA 94306
USA
Phone: +1.650.279.5903
Email: carlw@mcsr-labs.org
Cansever, et al. Expires May 14, 2008 [Page 8]
Internet-Draft 6LoWPAN Integration November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Cansever, et al. Expires May 14, 2008 [Page 9]
