idnits 2.17.1 draft-ikpark-core-shim-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RPL' is mentioned on line 74, but not defined == Unused Reference: 'RFC6550' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 318, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE Working Group Seunghun Oh 2 Internet Draft Shimkwon Yoon 3 Intended status: Standard Track Byungtak Lee 4 Expires: August 14, 2014 ETRI 5 Ilkyun Park 6 M2Soft 7 Namhi Kang 8 Duksung Women's University 9 February 14, 2014 11 Shim Header for CoAP Transfer over non-TCP/IP Networks 12 draft-ikpark-core-shim-02.txt 14 Abstract 16 This document defines shim header for the transfer of CoAP messages 17 over non-TCP/IP constrained networks. In this environment, IP and UDP 18 or TCP are not used, so that additional shim header as a container 19 for addresses of sender/receiver and the length of CoAP header and 20 its payload is required. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 14, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ................................................ 4 57 2. Terminology ................................................. 4 58 3. Shim Header ................................................. 5 59 3.1. Header Format .......................................... 5 60 3.2. Distinguishing between CoAP Header and Shim Header...... 6 61 3.3. Example ................................................ 7 62 4. Security Considerations...................................... 9 63 5. IANA Considerations ......................................... 9 64 6. Acknowledgments ............................................ 10 65 7. References ................................................. 10 66 7.1. Normative References .................................. 10 67 7.2. Informative References ................................ 10 69 1. Introduction 71 CoAP [CoAP] is a data transfer protocol over constrained nodes and 72 networks, e.g., 6LoWPAN. This protocol uses TCP/IP suit and some 73 other additional protocols designed for low-power and lossy networks 74 (LLN) like Routing Protocol for LLN (RPL) [RPL]. 76 Nowadays many kinds of sensor are applied in variable areas like 77 industry, building management, security service, environmental 78 monitoring and etc. Many of sensor manufactures are still reluctant 79 to use TCP/IP stack. TCP/IP still seems to be heavy to be applied to 80 the constrained node. Instead, they use various vender-specific 81 transfer protocols over various media like IEEE 802.15.4, RS485, CAN, 82 and RS232 (or UART). This is a big hurdle for CoAP to be prevalent. 84 In order to make it easy to apply CoAP to these non-TCP/IP 85 constrained node, we need to define new very simple header which 86 mimic IP header. But there are two restrictions on applying CoAP to 87 the non-TCP/IP nodes. The first is the lack of address. Peer-to-peer- 88 type media like UART and RS232 has no address to identify nodes. 89 RS485 has an integer value as an identifier, but there is no 90 standardized way to present or carry this value over networks. IEEE 91 802.15.4 has network address in their standard, but this address is 92 allocated by a coordinator dynamically. 64-bit-long extended address 93 is too long and sometimes not used. 95 The second restriction is that CoAP does not have PDU size 96 information in its header. CoAP calculates the PDU size with the 97 information from underlying protocol layer like the payload size in 98 IP header. 100 Therefore, in order to apply CoAP to non-TCP/IP nodes, new header for 101 CoAP must be defined to complement these two restrictions. In this 102 document, new Shim Header is specifies as a underlying protocol for 103 CoAP, and an example is added to explain this shim header. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119] when they appear in ALL CAPS. These words may also appear 111 in this document in lower case as plain English words, absent their 112 normative meanings. 114 Shim Header 116 In front of a CoAP header, a slim header is inserted instead of 117 IP header and this contains addresses of CoAP sender and receiver 118 and the length of CoAP header and its payload. 120 Local ID 122 A local ID is an address of CoAP sender or receiver, and it is 123 uniqueness in a vender-specific non-TCP/IP constrained network. 124 This ID has a 16-bit-long hexadecimal value, that is IEEE 125 802.15.4 network address compatible, and it can be extensible 126 later. 128 CoAP Proxy 130 A CoAP proxy in this document is a CoAP-to-CoAP proxy from [CoAP]. 131 In additional, this CoAP proxy can read and insert a shim header 132 from/to the front of CoAP header. 134 Additional terminology for CoAP can be found in [CoAP]. 136 3. Shim Header 138 3.1. Header Format 140 +----+----+---------+ 141 |Pre |Ver | Length | 142 +----+----+---------+ 143 | CoAP Src Local ID | 144 +-------------------+ 145 | CoAP Dst Local ID | 146 +-------------------+ 147 Figure 1 Shim Header Format 149 Fig. 1 shows a basic format of shim header. Next is the explanation 150 of each field in the header. 152 * Pre: it is abbreviation of Preamble, and a 4-bit-long field, 153 and has a meaning of the start of shim header. '0xa' is 154 used currently. 156 * Ver: it is abbreviation of Version, and also a 4-bit-long field. 157 Currently the version number is '1'. 159 * Length: it is the length of CoAP header and its payload 160 followed by the shim header. This has a value between 1 161 and 255. 163 * CoAP Source Local ID, CoAP Destination Local ID: are the local 164 IDs of the sender and receiver of its CoAP message. Each 165 field has 16-bit field. 167 Fig. 2 shows the extended format of shim header. This format is used 168 when the length of CoAP header and its payload is larger than 255. In 169 order to have an extended length field, the value of Length field is 170 set to '0', which means the next field is not CoAP source ID, but 16- 171 bit extended length field. This field can have a range of value from 172 0 to 65535. 174 +----+----+---------+ 175 |Pre |Ver | 0x00 | 176 +----+----+---------+ 177 | Ext. Length | 178 +-------------------+ 179 | CoAP Dst Local ID | 180 +-------------------+ 181 | CoAP Dst Local ID | 182 +-------------------+ 183 Figure 2 Shim Header Format with Extended Length 185 3.2. Distinguishing between CoAP Header and Shim Header 187 According to the type of constrained nodes, Shim header can be 188 hardcoded, or not be involved in the CoAP node implementation. But at 189 the following cases, CoAP and shim header must be distinguished when 190 a packet receiver of a node meets a start point of some header. 192 * The CoAP receiver has multiple heterogeneous media, and is not 193 able to identify the received interface among them. And some 194 media use shim header on their interfaces and the others are 195 not. 197 * The CoAP receiver receives CoAP messages from two or more other 198 CoAP nodes. 200 As a result, the start point of shim header must be differentiated 201 from it of CoAP header. According to the CoAP draft, CoAP header 202 starts with version and message type, which has a range of values 203 from 0x04 to 0x07. But in the case of shim header, it starts with 204 preamble field, and its value is '0xa' to identify shim header 205 against COAP header. 207 3.3. Example 209 As shown in [CoAP], the first example in Appendix A illustrates a 210 basic confirmable CoAP request and response in piggy-backed manner. 211 In this section, we add shim header to this example. In this case, 212 the client and the server are connected via non-TCP/IP. The client 213 can be a data collector node or a proxy node. The server may be a 214 temperature sensor. In this example, we assume that IDs of the client 215 and the server are 0x0000, and 0x0001 respectively. 217 Client Server 218 (0x0000) (0x0001) 219 | | 220 | | Shim: Length=16, Src=0x0000, Dst=0x0001 221 +----->| Header: GET (T=CON, Code=0.01, MID=0x7d34) 222 | GET | Uri-Path: "temperature" 223 | | 224 | | Shim: Length=11, Src=0x0001, Dst=0x0000 225 |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, 226 | | MID=0x7d34) 227 | 2.05 | Payload: "22.3 C" 228 | | 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | 0xa | 1 | Length=16 | Source ID=0x0000 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Destination ID=0x0001 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | 1 | 0 | 0 | GET=1 | MID=0x7d34 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | 11 | 11 | "temperature" (11 B) ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | 0xa | 1 | Length=11 | Source ID=0x0001 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Destination ID=0x0000 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | 1 | 2 | 0 | 2.05=69 | MID=0x7d34 | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 |1 1 1 1 1 1 1 1| "22.3 C" (6 B) ... 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 3 Message flow and Shim header 256 4. Security Considerations 258 The shim header for the transfer of CoAP messages is not intended to 259 use TCP/IP protocol suits. Fundamental motivation of the approach is 260 that lots of things (i.e. sensors and actuators) used in current 261 operation for several service domain as well as to be used as nodes 262 connected with Internet to build an IoT network frequently utilize 263 vender-specific protocols instead of TCP/IP protocols. Therefore, 264 several TCP/IP based security mechanisms cannot be used directly for 265 the approach in this draft. These are IKEv2, IPSec, DTLS, HIP and 266 others considered in [SecCon]. In particular, security binding to 267 DTLS, which is one of main features of CoAP, cannot work in a service 268 domain using shim header. 270 Instead, vendor specific secure protocols can be applied. Several 271 security protocols that can be standard solutions (e.g. security 272 architecture for ZigBee or EAP for IEEE 802.15.4) or proprietary 273 solutions have been proposed for several transmission media. Also, 274 development of secure scheme running in application layer can be an 275 alternative solution. 277 To use shim header in IoT, this draft considers heterogeneous 278 networks using different protocols suited for their transmission 279 media. A proxy box is required for the scenario. A CoAP-Shim proxy 280 supports protocol translation for allowing a node used shim header to 281 communicate with CoAP enabled nodes. 283 In case of using a proxy, end to end security and privacy are major 284 concerns from the aspect of security. If the proxy is infected or 285 spoofed, all messages translated by the proxy are simply eavesdropped, 286 modified, replayed, selectively forwarded and/or falsely delivered. 287 These attacks can subsequently lead to more serious threats. Several 288 vulnerabilities and possible threats to the CoAP have been well 289 described in [CoAP] and [SecCon]. Especially, section 11.2 of [CoAP] 290 presents security issues introduced by using proxy. In addition, 291 availability of proxy must be guaranteed even though computing power 292 and memory space are better than those of resource constrained nodes 293 in IoT. It is naturally obvious strategy that an attacker sends 294 flooded false packets to a proxy, thereby lunching denial-of-service 295 attacks since a death of proxy results in death of network used shim 296 header. 298 5. IANA Considerations 300 (TBD) 302 6. Acknowledgments 304 (TBD) 306 7. References 308 7.1. Normative References 310 [CoAP] Z. Shelby, K. Hartke, C. Bormann, "Constrained Application 311 Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013. 313 [RFC6550] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. 314 Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander, 315 "RPL: IPv6 Routing Protocol for Low-Power and Lossy 316 Networks", RFC 6550, March 2012. 318 [RFC4944] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, 319 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", 320 RFC 4944, September 2007. 322 7.2. Informative References 324 [RFC2119] S. Brander, "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [IEEE 802.15.4] IEEE Computer Society, "IEEE STd. 802.15.4-2003", 328 October 2003. 330 [SecCon] O. Garcia-Morchon, S. Kumar, S. Keoh, R. Hummen, R. Struik, 331 "Security Considerations in the IP-based Internet of 332 Things", draft-garcia-core-security-06, September 11, 2013. 334 Author's Addresses 336 Seung-Hun Oh 337 ETRI 338 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 339 Korea 340 Phone: +82-62-970-6655 341 Email: osh93@etri.re.kr 343 Shimkwon Yoon 344 ETRI 345 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 346 Korea 347 Phone: +82-62-970-6969 348 Email: yoonsk@etri.re.kr 350 Byung-Tak Lee 351 ETRI 352 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 353 Korea 354 Phone: +82-62-970-6624 355 Email: bytelee@etri.re.kr 357 Ilkyun Park 358 M2Soft 359 27 Seongsuiro7gil, Seongdong-gu, Seoul, 133-827, 360 Korea 361 Phone: +82-2-2188-8558 362 Email: ikpark@m2soft.co.kr 364 Namhi Kang 365 Duksung Women's University 366 419 Sangmoon-dong, Dobong-gu, Seoul, 132-714 367 Korea 368 Email: kang@duksung.ac.kr 369 URI: http://www.duksung.ac.kr