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]