CoRE Working Group Seunghun Oh Internet Draft Shimkwon Yoon Intended status: Standard Track Byungtak Lee Expires: August 14, 2014 ETRI Ilkyun Park M2Soft Namhi Kang Duksung Women's University February 14, 2014 Shim Header for CoAP Transfer over non-TCP/IP Networks draft-ikpark-core-shim-02.txt Abstract This document defines shim header for the transfer of CoAP messages over non-TCP/IP constrained networks. In this environment, IP and UDP or TCP are not used, so that additional shim header as a container for addresses of sender/receiver and the length of CoAP header and its payload is required. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 14, 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 documents carefully, as they describe your rights and restrictions with respect ikpark, et al. Expires April 16, 2014 [Page 1] Internet-Draft CoAP Shim Header October 2013 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. ikpark, et al. Expires April 16, 2014 [Page 2] Internet-Draft CoAP Shim Header October 2013 Table of Contents 1. Introduction ................................................ 4 2. Terminology ................................................. 4 3. Shim Header ................................................. 5 3.1. Header Format .......................................... 5 3.2. Distinguishing between CoAP Header and Shim Header...... 6 3.3. Example ................................................ 7 4. Security Considerations...................................... 9 5. IANA Considerations ......................................... 9 6. Acknowledgments ............................................ 10 7. References ................................................. 10 7.1. Normative References .................................. 10 7.2. Informative References ................................ 10 ikpark, et al. Expires April 16, 2014 [Page 3] Internet-Draft CoAP Shim Header October 2013 1. Introduction CoAP [CoAP] is a data transfer protocol over constrained nodes and networks, e.g., 6LoWPAN. This protocol uses TCP/IP suit and some other additional protocols designed for low-power and lossy networks (LLN) like Routing Protocol for LLN (RPL) [RPL]. Nowadays many kinds of sensor are applied in variable areas like industry, building management, security service, environmental monitoring and etc. Many of sensor manufactures are still reluctant to use TCP/IP stack. TCP/IP still seems to be heavy to be applied to the constrained node. Instead, they use various vender-specific transfer protocols over various media like IEEE 802.15.4, RS485, CAN, and RS232 (or UART). This is a big hurdle for CoAP to be prevalent. In order to make it easy to apply CoAP to these non-TCP/IP constrained node, we need to define new very simple header which mimic IP header. But there are two restrictions on applying CoAP to the non-TCP/IP nodes. The first is the lack of address. Peer-to-peer- type media like UART and RS232 has no address to identify nodes. RS485 has an integer value as an identifier, but there is no standardized way to present or carry this value over networks. IEEE 802.15.4 has network address in their standard, but this address is allocated by a coordinator dynamically. 64-bit-long extended address is too long and sometimes not used. The second restriction is that CoAP does not have PDU size information in its header. CoAP calculates the PDU size with the information from underlying protocol layer like the payload size in IP header. Therefore, in order to apply CoAP to non-TCP/IP nodes, new header for CoAP must be defined to complement these two restrictions. In this document, new Shim Header is specifies as a underlying protocol for CoAP, and an example is added to explain this shim header. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. ikpark, et al. Expires April 16, 2014 [Page 4] Internet-Draft CoAP Shim Header October 2013 Shim Header In front of a CoAP header, a slim header is inserted instead of IP header and this contains addresses of CoAP sender and receiver and the length of CoAP header and its payload. Local ID A local ID is an address of CoAP sender or receiver, and it is uniqueness in a vender-specific non-TCP/IP constrained network. This ID has a 16-bit-long hexadecimal value, that is IEEE 802.15.4 network address compatible, and it can be extensible later. CoAP Proxy A CoAP proxy in this document is a CoAP-to-CoAP proxy from [CoAP]. In additional, this CoAP proxy can read and insert a shim header from/to the front of CoAP header. Additional terminology for CoAP can be found in [CoAP]. 3. Shim Header 3.1. Header Format +----+----+---------+ |Pre |Ver | Length | +----+----+---------+ | CoAP Src Local ID | +-------------------+ | CoAP Dst Local ID | +-------------------+ Figure 1 Shim Header Format Fig. 1 shows a basic format of shim header. Next is the explanation of each field in the header. * Pre: it is abbreviation of Preamble, and a 4-bit-long field, and has a meaning of the start of shim header. '0xa' is used currently. ikpark, et al. Expires April 16, 2014 [Page 5] Internet-Draft CoAP Shim Header October 2013 * Ver: it is abbreviation of Version, and also a 4-bit-long field. Currently the version number is '1'. * Length: it is the length of CoAP header and its payload followed by the shim header. This has a value between 1 and 255. * CoAP Source Local ID, CoAP Destination Local ID: are the local IDs of the sender and receiver of its CoAP message. Each field has 16-bit field. Fig. 2 shows the extended format of shim header. This format is used when the length of CoAP header and its payload is larger than 255. In order to have an extended length field, the value of Length field is set to '0', which means the next field is not CoAP source ID, but 16- bit extended length field. This field can have a range of value from 0 to 65535. +----+----+---------+ |Pre |Ver | 0x00 | +----+----+---------+ | Ext. Length | +-------------------+ | CoAP Dst Local ID | +-------------------+ | CoAP Dst Local ID | +-------------------+ Figure 2 Shim Header Format with Extended Length 3.2. Distinguishing between CoAP Header and Shim Header According to the type of constrained nodes, Shim header can be hardcoded, or not be involved in the CoAP node implementation. But at the following cases, CoAP and shim header must be distinguished when a packet receiver of a node meets a start point of some header. * The CoAP receiver has multiple heterogeneous media, and is not able to identify the received interface among them. And some media use shim header on their interfaces and the others are not. * The CoAP receiver receives CoAP messages from two or more other CoAP nodes. ikpark, et al. Expires April 16, 2014 [Page 6] Internet-Draft CoAP Shim Header October 2013 As a result, the start point of shim header must be differentiated from it of CoAP header. According to the CoAP draft, CoAP header starts with version and message type, which has a range of values from 0x04 to 0x07. But in the case of shim header, it starts with preamble field, and its value is '0xa' to identify shim header against COAP header. 3.3. Example As shown in [CoAP], the first example in Appendix A illustrates a basic confirmable CoAP request and response in piggy-backed manner. In this section, we add shim header to this example. In this case, the client and the server are connected via non-TCP/IP. The client can be a data collector node or a proxy node. The server may be a temperature sensor. In this example, we assume that IDs of the client and the server are 0x0000, and 0x0001 respectively. ikpark, et al. Expires April 16, 2014 [Page 7] Internet-Draft CoAP Shim Header October 2013 Client Server (0x0000) (0x0001) | | | | Shim: Length=16, Src=0x0000, Dst=0x0001 +----->| Header: GET (T=CON, Code=0.01, MID=0x7d34) | GET | Uri-Path: "temperature" | | | | Shim: Length=11, Src=0x0001, Dst=0x0000 |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, | | MID=0x7d34) | 2.05 | Payload: "22.3 C" | | 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xa | 1 | Length=16 | Source ID=0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID=0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 0 | GET=1 | MID=0x7d34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 11 | "temperature" (11 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xa | 1 | Length=11 | Source ID=0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination ID=0x0000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 0 | 2.05=69 | MID=0x7d34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| "22.3 C" (6 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Message flow and Shim header ikpark, et al. Expires April 16, 2014 [Page 8] Internet-Draft CoAP Shim Header October 2013 4. Security Considerations The shim header for the transfer of CoAP messages is not intended to use TCP/IP protocol suits. Fundamental motivation of the approach is that lots of things (i.e. sensors and actuators) used in current operation for several service domain as well as to be used as nodes connected with Internet to build an IoT network frequently utilize vender-specific protocols instead of TCP/IP protocols. Therefore, several TCP/IP based security mechanisms cannot be used directly for the approach in this draft. These are IKEv2, IPSec, DTLS, HIP and others considered in [SecCon]. In particular, security binding to DTLS, which is one of main features of CoAP, cannot work in a service domain using shim header. Instead, vendor specific secure protocols can be applied. Several security protocols that can be standard solutions (e.g. security architecture for ZigBee or EAP for IEEE 802.15.4) or proprietary solutions have been proposed for several transmission media. Also, development of secure scheme running in application layer can be an alternative solution. To use shim header in IoT, this draft considers heterogeneous networks using different protocols suited for their transmission media. A proxy box is required for the scenario. A CoAP-Shim proxy supports protocol translation for allowing a node used shim header to communicate with CoAP enabled nodes. In case of using a proxy, end to end security and privacy are major concerns from the aspect of security. If the proxy is infected or spoofed, all messages translated by the proxy are simply eavesdropped, modified, replayed, selectively forwarded and/or falsely delivered. These attacks can subsequently lead to more serious threats. Several vulnerabilities and possible threats to the CoAP have been well described in [CoAP] and [SecCon]. Especially, section 11.2 of [CoAP] presents security issues introduced by using proxy. In addition, availability of proxy must be guaranteed even though computing power and memory space are better than those of resource constrained nodes in IoT. It is naturally obvious strategy that an attacker sends flooded false packets to a proxy, thereby lunching denial-of-service attacks since a death of proxy results in death of network used shim header. 5. IANA Considerations (TBD) ikpark, et al. Expires April 16, 2014 [Page 9] Internet-Draft CoAP Shim Header October 2013 6. Acknowledgments (TBD) 7. References 7.1. Normative References [CoAP] Z. Shelby, K. Hartke, C. Bormann, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013. [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", RFC 6550, March 2012. [RFC4944] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. 7.2. Informative References [RFC2119] S. Brander, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IEEE 802.15.4] IEEE Computer Society, "IEEE STd. 802.15.4-2003", October 2003. [SecCon] O. Garcia-Morchon, S. Kumar, S. Keoh, R. Hummen, R. Struik, "Security Considerations in the IP-based Internet of Things", draft-garcia-core-security-06, September 11, 2013. ikpark, et al. Expires April 16, 2014 [Page 10] Internet-Draft CoAP Shim Header October 2013 Author's Addresses Seung-Hun Oh ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6655 Email: osh93@etri.re.kr Shimkwon Yoon ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6969 Email: yoonsk@etri.re.kr Byung-Tak Lee ETRI 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, Korea Phone: +82-62-970-6624 Email: bytelee@etri.re.kr Ilkyun Park M2Soft 27 Seongsuiro7gil, Seongdong-gu, Seoul, 133-827, Korea Phone: +82-2-2188-8558 Email: ikpark@m2soft.co.kr Namhi Kang Duksung Women's University 419 Sangmoon-dong, Dobong-gu, Seoul, 132-714 Korea Email: kang@duksung.ac.kr URI: http://www.duksung.ac.kr ikpark, et al. Expires April 16, 2014 [Page 11]