Internet-Draft CoRE Working Group -- Overview March 2020
Bormann & Jimenez Expires 24 September 2020 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-bormann-core-overview-00
Published:
Intended Status:
Informational
Expires:
Authors:
C. Bormann
Universitaet Bremen TZI
J.J. Jimenez
Ericsson

CoRE Working Group -- Overview

Abstract

The IETF "Constrained RESTful Environments" (CoRE) Working Group standardizes application layer protocols that can be used by resource-constrained devices, as can be found in the Internet of Things (IoT). It is part of a cluster of about a dozen IETF WGs defining specifications for these environments.

This short document provides an overview of the activies of the CoRE WG as of end of March, 2020.

Status of This Memo

This Internet-Draft is submitted 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 https://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 24 September 2020.

Table of Contents

1. Introduction

The IETF "Constrained RESTful Environments" (CoRE) Working Group standardizes application layer protocols that can be used by resource-constrained devices, as can be found in the Internet of Things (IoT). It is part of a cluster of about a dozen IETF WGs that define networking (e.g., 6Lo), routing (e.g., ROLL), and security (e.g., ACE, LAKE, SUIT) for these environments. This cluster has been growing since 2005; ten years ago, on 2010-03-09, CoRE was added to it.

2. Main Specification

The main specification of CoRE is the Constrained Application Protocol (CoAP) [RFC7252]. CoAP is for applications including constrained devices what HTTP is for general purpose applications. By using UDP as the transport protocol as opposed to HTTP's use of TCP, and by removing much of the baggage of of HTTP, CoAP can be run on quite simple platforms and with very little power use. Both protocols share the Representational State Transfer (REST) architecture, the same set of verbs (GET, PUT, POST, DELETE), and quite similar semantics.

Since CoAP's approval in 2013, further specifications have been added to support the Observe pattern of change notifications from a server (low-complexity server-push) [RFC7641], to support larger transfers [RFC7959], to add verbs (FETCH, PATCH, and idempotent iPATCH [RFC8132]), and to enable the use of CoAP over TCP [RFC8323]. [RFC8768] recently added a way to detect and mitigate loops in a proxy configuration, motivated by the requirements of the Distributed Denial-of-Service Open Threat Signaling (DOTS [I-D.ietf-dots-signal-channel]) specification.

Two further extensions are now in completion: reducing the need for per-request state in clients and proxies [I-D.ietf-core-stateless] (in IETF last call) and improving the security between multiple active requests [I-D.ietf-core-echo-request-tag], further reducing CoAP's exploitability in denial of service attacks (completed working-group last call).

3. Security

Security has always been a critical enabler for IoT. Similar to the way the HTTP web uses TLS, CoAP was kicked off with a security architecture based on Datagram TLS (DTLS), which provides high levels of security, but does not support end-to-end security in a configuration that includes proxies. Object Security for CoRE (OSCORE) now provides end-to-end security over proxy paths that may include both CoAP and HTTP [RFC8613].

One interesting aspect of OSCORE is that it also supports group communication, as it occurs in multicasting requests to collect responses from a group of nodes. CoAP has supported multicast requests from the outset, and [RFC7390], Group Communication on top of IP multicast, provides additional specfication for this. As DTLS only supports unicast, without a security architecture RFC 7390 was published an experimental RFC. Work is now underway to revise this RFC [I-D.dijk-core-groupcomm-bis], which includes making use of the capabilities provided by OSCORE for group communication [I-D.ietf-core-oscore-groupcomm]. Work is now under way in the CoRE, ACE, and LAKE working groups to complement this basis with additional specifications making use of OSCORE and CoAP group communication.

4. Operations and Management

IoT systems need to support a large number of nodes, which need to be configured and integrated into an IoT system. A discovery and self-description architecture based on web links has been the first product of the WG [RFC6690], which is now being complemented by a registration and discovery function (CoRE Resource Directory [I-D.ietf-core-resource-directory], in IESG processing).

Constrained nodes also need management functions. While many IoT SDOs are integrating these right into their IoT data format specifications, the IETF has its own architecture for describing management information, YANG [RFC7950]. The "CORECONF" specifications that are in Working Group Last Call (including YANG-CBOR [I-D.ietf-core-yang-cbor]) make this widely used approach of providing management interfaces available in a highly efficient way that is applicable to constrained environments, as our complement to the established YANG protocols NETCONF and RESTCONF.

5. Data Formats

While CoAP can be used with many different data formats, a simple CoRE format for sensor and actuator data, Sensor Measurement Lists (SenML), was defined in [RFC8428]. Recently, a number of specifications have been readied in support of SenML that are now undergoing final processing by the RFC editor: Support for the RFC 8132 verbs [I-D.ietf-core-senml-etch], and modifications to the SenML units registry [I-D.ietf-core-senml-more-units] that make it more accessible as a basis for data format standards of other Standards Development Organizations (SDOs). A foundation for further data format specification that combines the web-linking approach of RFC 6690 with more modern data representation techniques is now being worked on under the name CoRAL [I-D.ietf-core-coral]; application specifications such as CoAP pubsub [I-D.ietf-core-coap-pubsub] are expected to pivot to this basis.

6. Further Information

To follow and contribute to CoRE's work, please refer to the core status page (https://tools.ietf.org/wg/core/) and join the core mailing list: core@ietf.org via https://www.ietf.org/mailman/listinfo/core.

7. Informative References

[I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-dijk-core-groupcomm-bis-03, , <http://www.ietf.org/internet-drafts/draft-dijk-core-groupcomm-bis-03.txt>.
[I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-coap-pubsub-09, , <http://www.ietf.org/internet-drafts/draft-ietf-core-coap-pubsub-09.txt>.
[I-D.ietf-core-coral]
Hartke, K., "The Constrained RESTful Application Language (CoRAL)", Work in Progress, Internet-Draft, draft-ietf-core-coral-03, , <http://www.ietf.org/internet-drafts/draft-ietf-core-coral-03.txt>.
[I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, Internet-Draft, draft-ietf-core-echo-request-tag-09, , <http://www.ietf.org/internet-drafts/draft-ietf-core-echo-request-tag-09.txt>.
[I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, Internet-Draft, draft-ietf-core-oscore-groupcomm-07, , <http://www.ietf.org/internet-drafts/draft-ietf-core-oscore-groupcomm-07.txt>.
[I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", Work in Progress, Internet-Draft, draft-ietf-core-resource-directory-24, , <http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-24.txt>.
[I-D.ietf-core-senml-etch]
Keranen, A. and M. Mohajer, "FETCH & PATCH with Sensor Measurement Lists (SenML)", Work in Progress, Internet-Draft, draft-ietf-core-senml-etch-07, , <http://www.ietf.org/internet-drafts/draft-ietf-core-senml-etch-07.txt>.
[I-D.ietf-core-senml-more-units]
Bormann, C., "Additional Units for SenML", Work in Progress, Internet-Draft, draft-ietf-core-senml-more-units-06, , <http://www.ietf.org/internet-drafts/draft-ietf-core-senml-more-units-06.txt>.
[I-D.ietf-core-stateless]
Hartke, K., "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-stateless-05, , <http://www.ietf.org/internet-drafts/draft-ietf-core-stateless-05.txt>.
[I-D.ietf-core-yang-cbor]
Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of Data Modeled with YANG", Work in Progress, Internet-Draft, draft-ietf-core-yang-cbor-12, , <http://www.ietf.org/internet-drafts/draft-ietf-core-yang-cbor-12.txt>.
[I-D.ietf-dots-signal-channel]
Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", Work in Progress, Internet-Draft, draft-ietf-dots-signal-channel-41, , <http://www.ietf.org/internet-drafts/draft-ietf-dots-signal-channel-41.txt>.
[RFC6690]
Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, , <https://www.rfc-editor.org/info/rfc6690>.
[RFC7252]
Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, , <https://www.rfc-editor.org/info/rfc7252>.
[RFC7390]
Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, , <https://www.rfc-editor.org/info/rfc7390>.
[RFC7641]
Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, , <https://www.rfc-editor.org/info/rfc7641>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/info/rfc7950>.
[RFC7959]
Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, , <https://www.rfc-editor.org/info/rfc7959>.
[RFC8132]
van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, , <https://www.rfc-editor.org/info/rfc8132>.
[RFC8323]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, , <https://www.rfc-editor.org/info/rfc8323>.
[RFC8428]
Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, , <https://www.rfc-editor.org/info/rfc8428>.
[RFC8613]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, , <https://www.rfc-editor.org/info/rfc8613>.
[RFC8768]
Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained Application Protocol (CoAP) Hop-Limit Option", RFC 8768, DOI 10.17487/RFC8768, , <https://www.rfc-editor.org/info/rfc8768>.

Acknowledgements

Marco Tiloca provided comments on a draft of this document.

Authors' Addresses

Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Jaime Jimenez
Ericsson