idnits 2.17.1 draft-amsuess-core-coap-over-gatt-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (4 March 2020) is 1514 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 4 March 2020 4 Intended status: Experimental 5 Expires: 5 September 2020 7 CoAP over GATT (Bluetooth Low Energy Generic Attributes) 8 draft-amsuess-core-coap-over-gatt-00 10 Abstract 12 Interaction from computers and cell phones to constrained devices is 13 limited by the different network technologies used, and by the 14 available APIs. This document describes a transport for the 15 Constrained Application Protocol (CoAP) that uses Bluetooth GATT 16 (Generic Attribute Profile) and its use cases. 18 Note to Readers 20 Discussion of this document takes place on the CORE Working Group 21 mailing list (core@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/browse/core/ 23 (https://mailarchive.ietf.org/arch/browse/core/). 25 Source for this draft and an issue tracker can be found at 26 https://gitlab.com/chrysn/coap-over-gatt/ (https://gitlab.com/chrysn/ 27 coap-over-gatt/-/tree/master). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 5 September 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Procedural status . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Appplication example . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol description . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Requests and responses . . . . . . . . . . . . . . . . . 4 68 3.2. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2.1. Scheme-free alternative . . . . . . . . . . . . . . . 5 70 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Uniform Resource Identifier (URI) Schemes . . . . . . . . 5 72 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 75 6.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 78 1. Introduction 80 The Constrained Application Protocol (CoAP) [RFC7252] can be used 81 with different network and transport technologies, for example UDP on 82 6LoWPAN networks. 84 Not all those network technologies are available at end user devices 85 in the vicinity of the constrained devices, which inhibits direct 86 communication and necessitates the use of gateway devices or cloud 87 services. In particular, 6LoWPAN is not available at all in typical 88 end user devices, and while 6LoWPAN-over-BLE (IPSP, the Internet 89 Protocol Support Profile of Bluetooth Low Energy (BLE), [RFC7668]) 90 might be compatible from a radio point of view, many operating 91 systems or platforms lack support for it, especially in a user- 92 accessible way. 94 As a workaround to access constrained CoAP devices from end user 95 devices, this document describes a way encapsulate generic CoAP 96 exchanges in Bluetooth GATT (Generic Attribute Profile). This is 97 explicitly not designed as means of communication between two devices 98 in full control of themselves - those should rather build an IP based 99 network and transport CoAP as originally specified. It is intended 100 as a means for an application to escape the limitations of its 101 environment, with a special focus on web applications that use the 102 Web Bluetooth [webbluetooth]. In that, it is similar to CoAP-over- 103 WebSockets [RFC8323]. 105 1.1. Procedural status 107 [ This section will be removed before publication. ] 109 The path of this document is currently not clear. It might attract 110 interest in the CoRE working group, but might be easier to process as 111 an indpenendent submission. 113 1.2. Appplication example 115 Consider a network of home automation light bulbs and switches, which 116 internally uses CoAP on a 6LoWPAN network and whose basic pairing 117 configuration can be done without additional electronic devices. 119 Without CoAP-over-GATT, an application that offers advanced 120 configuration requires the use of a dedicated gateway device or a 121 router that is equipped and configured to forward between the 6LoWPAN 122 and the local network. In practice, this is often delivered as a 123 wired gateway device and a custom app. 125 With CoAP-over-GATT, the light bulbs can advertise themselves via 126 BLE, and the configuration application can run as a web site. The 127 user navigates to that web site, and it asks permission to contact 128 the light bulbs using Web Bluetooth. The web application can then 129 exchange CoAP messages directly with the light bulb, and have it 130 proxy requests to other devices connected in the 6LoWPAN network. 132 For browsers that do not support Web Bluetooth, the same web 133 application can be packaged into an native application consisting of 134 a proxy process that forwards requests received via CoAP-over- 135 WebSockets on the loopback interface to CoAP-over-GATT, and a browser 136 view that runs the original web application in a configuration to use 137 WebSockets rather than CoAP-over-GATT. 139 That connection is no replacement when remote control of the system 140 is desired (in which case, again, a router is required that 141 translates 6LoWPAN to the rest of the network), but suffices for many 142 commissioning tasks. 144 2. Terminology 146 3. Protocol description 148 3.1. Requests and responses 150 [ This section is not thought through or implemented yet, and could 151 probably end up very different. ] 153 CoAP-over-GATT uses individual GATT Characteristics to model a 154 reliable request-response mechanism. Therefore, it has no message 155 types or message IDs (in which it resembles CoAP-over-TCP [RFC8323]), 156 and no tokens. In the place of tokens, . All messages use GATT to 157 ensure reliable transmission. 159 A GATT server announces service of UUID 8df804b7-3300-496d-9dfa- 160 f8fb40a236bc (abbreviated US in this document), with one or more 161 characteristics of UUID 2a58fc3f-3c62-4ecc-8167-d66d4d9410c2 162 (abbreviated UC). 164 [ Right now, this only supports requests from the GATT client to the 165 GATT server; role reversal might be added later. ] 167 A client can start a CoAP request by writing to the UC characteristic 168 a sequence composed of a single code byte, any options encoded in the 169 option format of [RFC7252] Section 3.1, optionally followed by a 170 payload marker and the request payload. 172 After the successful write, the client can read the response back 173 from the server on the same characteristic. The client may need to 174 attempt reading the characteristic several times until the response 175 is ready, and may subscribe to indications to get notifiied when the 176 response is ready. 178 The server does not need to keep the response readable after it has 179 been read successfully. 181 If the request and initial response establish an observation, the 182 client may keep reading; the server may keep the latest notification 183 available indefinitely (especially if it turns out that "has been 184 read successfully" is hard to determine) or make it readable only 185 once for each new state. 187 Once the client writes a new request to a UC characteristic, any 188 later reads pertain to that request, and any observation previously 189 established is cancelled implicitly. 191 Attribute values are limited to 512 Bytes ([bluetooth52] Part F 192 Section 3.2.9), practically limiting blockwise operation ([RFC7959]) 193 to size exponents to 4 (resulting in a block size of 256 byte). Even 194 smaller messages might enhance the transfer efficiency when they 195 avoid fragmentation at the L2CAP level. 197 If a server provides multiple OC typed characteristics, parallel 198 requests or observations are possible; otherwise, this transport is 199 limited to a single pending request. 201 3.2. Addresses 203 [ ... coap+bluetooth://00-11-22-33-44-55-66-77-88-99/.well-known/core 204 ... ] 206 Note that when using Web Bluetooth [webbluetooth], neither the own 207 nor the peer's address are known to the application. They may come 208 up with an application-internal authority component (e. g. 209 "coap+bluetooth://id-SomeInternalIdentifier/.well-known/core"), but 210 must be aware that those can not be expressed towards anything 211 outside the local stack. 213 3.2.1. Scheme-free alternative 215 As an alternative to the abovementioned scheme, a zone in .arpa could 216 be registered to use addresses like 218 coap://001122334455.ble.arpa/.well-known/core 220 where the .ble.arpa address do not resolve to any IP addresses. 222 [ Accepting this will require a .arpa registering IANA consideration 223 to replace the URI one. ] 225 4. IANA considerations 227 4.1. Uniform Resource Identifier (URI) Schemes 229 IANA is asked to enter a new scheme into the "Uniform Resource 230 Identifier (URI) Schemes" registry set up in [RFC7595]: 232 * URI Scheme: "coap+gatt" 234 * Description: CoAP over Bluetooth GATT (sharing the footnote of 235 coap+tcp) 237 * Well-Known URI Support: yes, analogous to [RFC7252] 239 5. Security considerations 241 All data received over GATT is considered untrusted; secure 242 communication can be achieved using OSCORE [RFC8613]. 244 Physical proximity can not be inferred from this means of 245 communication. 247 6. References 249 6.1. Normative References 251 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 252 Application Protocol (CoAP)", RFC 7252, 253 DOI 10.17487/RFC7252, June 2014, 254 . 256 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 257 and Registration Procedures for URI Schemes", BCP 35, 258 RFC 7595, DOI 10.17487/RFC7595, June 2015, 259 . 261 6.2. Informative References 263 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 264 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 265 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 266 . 268 [webbluetooth] 269 Grant, R. and O. Ruiz-Henríquez, "Web Bluetooth", 24 270 February 2020, 271 . 273 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 274 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 275 Application Protocol) over TCP, TLS, and WebSockets", 276 RFC 8323, DOI 10.17487/RFC8323, February 2018, 277 . 279 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 280 "Object Security for Constrained RESTful Environments 281 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 282 . 284 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 285 the Constrained Application Protocol (CoAP)", RFC 7959, 286 DOI 10.17487/RFC7959, August 2016, 287 . 289 [bluetooth52] 290 "Bluetooth Core Specification v5.2", 31 December 2019, 291 . 294 Author's Address 296 Christian Amsüss 297 Austria 299 Email: christian@amsuess.com