idnits 2.17.00 (12 Aug 2021) /tmp/idnits26419/draft-amsuess-core-coap-over-gatt-01.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 (2 November 2020) is 558 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-bormann-core-responses-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsüss 3 Internet-Draft 2 November 2020 4 Intended status: Experimental 5 Expires: 6 May 2021 7 CoAP over GATT (Bluetooth Low Energy Generic Attributes) 8 draft-amsuess-core-coap-over-gatt-01 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 6 May 2021. 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 3.3. Compression and reinterpretation of non-CoAP 71 characteristics . . . . . . . . . . . . . . . . . . . . . 6 72 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Uniform Resource Identifier (URI) Schemes . . . . . . . . 6 74 5. Security considerations . . . . . . . . . . . . . . . . . . . 6 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 6.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The Constrained Application Protocol (CoAP) [RFC7252] can be used 84 with different network and transport technologies, for example UDP on 85 6LoWPAN networks. 87 Not all those network technologies are available at end user devices 88 in the vicinity of the constrained devices, which inhibits direct 89 communication and necessitates the use of gateway devices or cloud 90 services. In particular, 6LoWPAN is not available at all in typical 91 end user devices, and while 6LoWPAN-over-BLE (IPSP, the Internet 92 Protocol Support Profile of Bluetooth Low Energy (BLE), [RFC7668]) 93 might be compatible from a radio point of view, many operating 94 systems or platforms lack support for it, especially in a user- 95 accessible way. 97 As a workaround to access constrained CoAP devices from end user 98 devices, this document describes a way encapsulate generic CoAP 99 exchanges in Bluetooth GATT (Generic Attribute Profile). This is 100 explicitly not designed as means of communication between two devices 101 in full control of themselves - those should rather build an IP based 102 network and transport CoAP as originally specified. It is intended 103 as a means for an application to escape the limitations of its 104 environment, with a special focus on web applications that use the 105 Web Bluetooth [webbluetooth]. In that, it is similar to CoAP-over- 106 WebSockets [RFC8323]. 108 1.1. Procedural status 110 [ This section will be removed before publication. ] 112 The path of this document is currently not clear. It might attract 113 interest in the CoRE working group, but might be easier to process as 114 an indpenendent submission. 116 1.2. Appplication example 118 Consider a network of home automation light bulbs and switches, which 119 internally uses CoAP on a 6LoWPAN network and whose basic pairing 120 configuration can be done without additional electronic devices. 122 Without CoAP-over-GATT, an application that offers advanced 123 configuration requires the use of a dedicated gateway device or a 124 router that is equipped and configured to forward between the 6LoWPAN 125 and the local network. In practice, this is often delivered as a 126 wired gateway device and a custom app. 128 With CoAP-over-GATT, the light bulbs can advertise themselves via 129 BLE, and the configuration application can run as a web site. The 130 user navigates to that web site, and it asks permission to contact 131 the light bulbs using Web Bluetooth. The web application can then 132 exchange CoAP messages directly with the light bulb, and have it 133 proxy requests to other devices connected in the 6LoWPAN network. 135 For browsers that do not support Web Bluetooth, the same web 136 application can be packaged into an native application consisting of 137 a proxy process that forwards requests received via CoAP-over- 138 WebSockets on the loopback interface to CoAP-over-GATT, and a browser 139 view that runs the original web application in a configuration to use 140 WebSockets rather than CoAP-over-GATT. 142 That connection is no replacement when remote control of the system 143 is desired (in which case, again, a router is required that 144 translates 6LoWPAN to the rest of the network), but suffices for many 145 commissioning tasks. 147 2. Terminology 149 3. Protocol description 151 3.1. Requests and responses 153 [ This section is not thought through or implemented yet, and could 154 probably end up very different. ] 156 CoAP-over-GATT uses individual GATT Characteristics to model a 157 reliable request-response mechanism. Therefore, it has no message 158 types or message IDs (in which it resembles CoAP-over-TCP [RFC8323]), 159 and no tokens. In the place of tokens, different Bluetooth 160 characteristics (comparable to open ports in IP based networks) can 161 be used. All messages use GATT to ensure reliable transmission. 163 A GATT server announces service of UUID 8df804b7-3300-496d-9dfa- 164 f8fb40a236bc (abbreviated US in this document), with one or more 165 characteristics of UUID 2a58fc3f-3c62-4ecc-8167-d66d4d9410c2 166 (abbreviated UC). 168 [ Right now, this only supports requests from the GATT client to the 169 GATT server; role reversal might be added later. ] 171 A client can start a CoAP request by writing to the UC characteristic 172 a sequence composed of a single code byte, any options encoded in the 173 option format of [RFC7252] Section 3.1, optionally followed by a 174 payload marker and the request payload. 176 After the successful write, the client can read the response back 177 from the server on the same characteristic. The client may need to 178 attempt reading the characteristic several times until the response 179 is ready, and may subscribe to indications to get notifiied when the 180 response is ready. 182 The server does not need to keep the response readable after it has 183 been read successfully. 185 If the request and initial response establish an observation, the 186 client may keep reading; the server may keep the latest notification 187 available indefinitely (especially if it turns out that "has been 188 read successfully" is hard to determine) or make it readable only 189 once for each new state. 191 Once the client writes a new request to a UC characteristic, any 192 later reads pertain to that request, and any observation previously 193 established is cancelled implicitly. 195 Attribute values are limited to 512 Bytes ([bluetooth52] Part F 196 Section 3.2.9), practically limiting blockwise operation ([RFC7959]) 197 to size exponents to 4 (resulting in a block size of 256 byte). Even 198 smaller messages might enhance the transfer efficiency when they 199 avoid fragmentation at the L2CAP level. 201 If a server provides multiple OC typed characteristics, parallel 202 requests or observations are possible; otherwise, this transport is 203 limited to a single pending request. 205 3.2. Addresses 207 [ ... coap+bluetooth://00-11-22-33-44-55-66-77-88-99/.well-known/core 208 ... ] 210 Note that when using Web Bluetooth [webbluetooth], neither the own 211 nor the peer's address are known to the application. They may come 212 up with an application-internal authority component (e. g. 213 "coap+bluetooth://id-SomeInternalIdentifier/.well-known/core"), but 214 must be aware that those can not be expressed towards anything 215 outside the local stack. 217 3.2.1. Scheme-free alternative 219 As an alternative to the abovementioned scheme, a zone in .arpa could 220 be registered to use addresses like 222 coap://001122334455.ble.arpa/.well-known/core 224 where the .ble.arpa address do not resolve to any IP addresses. 226 [ Accepting this will require a .arpa registering IANA consideration 227 to replace the URI one. ] 229 3.3. Compression and reinterpretation of non-CoAP characteristics 231 The use of SCHC is being evaluated in combination with CoAP-over- 232 GATT; the device can use the characteristic UUID to announce the 233 static context used. 235 Together with non-traditional response forms 236 ([I-D.bormann-core-responses] and contexts that expand, say, a 237 numeric value 0x1234 to a message like 239 "2.05 Content Response-For: GET /temperature Content-Format: 240 application/senml+cbor Payload (in JSON-ish equivalent): [ {1 /* unit 241 */: "K", 2 /* value */: 0x1234} ]" 243 This enables a different use case than dealing with limited 244 environments: Accessing BLE devices via CoAP without application 245 specific gateways. Any required information about the application 246 can be expressed in the SCHC context. 248 4. IANA considerations 250 4.1. Uniform Resource Identifier (URI) Schemes 252 IANA is asked to enter a new scheme into the "Uniform Resource 253 Identifier (URI) Schemes" registry set up in [RFC7595]: 255 * URI Scheme: "coap+gatt" 257 * Description: CoAP over Bluetooth GATT (sharing the footnote of 258 coap+tcp) 260 * Well-Known URI Support: yes, analogous to [RFC7252] 262 5. Security considerations 264 All data received over GATT is considered untrusted; secure 265 communication can be achieved using OSCORE [RFC8613]. 267 Physical proximity can not be inferred from this means of 268 communication. 270 6. References 272 6.1. Normative References 274 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 275 Application Protocol (CoAP)", RFC 7252, 276 DOI 10.17487/RFC7252, June 2014, 277 . 279 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 280 and Registration Procedures for URI Schemes", BCP 35, 281 RFC 7595, DOI 10.17487/RFC7595, June 2015, 282 . 284 6.2. Informative References 286 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 287 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 288 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 289 . 291 [webbluetooth] 292 Grant, R. and O. Ruiz-Henríquez, "Web Bluetooth", 24 293 February 2020, 294 . 296 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 297 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 298 Application Protocol) over TCP, TLS, and WebSockets", 299 RFC 8323, DOI 10.17487/RFC8323, February 2018, 300 . 302 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 303 "Object Security for Constrained RESTful Environments 304 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 305 . 307 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 308 the Constrained Application Protocol (CoAP)", RFC 7959, 309 DOI 10.17487/RFC7959, August 2016, 310 . 312 [bluetooth52] 313 "Bluetooth Core Specification v5.2", 31 December 2019, 314 . 317 [I-D.bormann-core-responses] 318 Bormann, C., "CoAP: Non-traditional response forms", Work 319 in Progress, Internet-Draft, draft-bormann-core-responses- 320 00, 12 November 2017, . 323 Appendix A. Change log 325 Since -00: 327 * Add note on SCHC possibilities. 329 Author's Address 331 Christian Amsüss 332 Austria 334 Email: christian@amsuess.com