CoRE Working Group -- Overview
Universitaet Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
Ericsson
jaime.jimenez@ericsson.com
Internet-Draft
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 .
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.
Copyright Notice
Copyright (c) 2020 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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect 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.
Table of Contents
-
. Introduction
-
. Main Specification
-
. Security
-
. Operations and Management
-
. Data Formats
-
. Further Information
-
. Informative References
-
Acknowledgements
-
Authors' Addresses
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.
Main Specification
The main specification of CoRE is the Constrained Application Protocol (CoAP) . 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) , to support larger transfers , to add verbs (FETCH, PATCH, and idempotent iPATCH ), and to enable the use of CoAP over TCP . 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 ) specification.
Two further extensions are now in completion: reducing the need for per-request state in clients and proxies (in IETF last call) and improving the security between multiple active requests , further reducing CoAP's exploitability in denial of service attacks (completed working-group last call).
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 .
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 ,
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 , which includes making use of the capabilities provided by OSCORE for group communication . 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.
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 , which is now being complemented by a registration and discovery function (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 . The "CORECONF" specifications that are in Working Group Last Call (including 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.
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 . 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 , and modifications to the SenML units registry 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 ; application specifications such as CoAP pubsub are expected to pivot to this basis.
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.
Informative References
Group Communication for the Constrained Application Protocol (CoAP)
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, using UDP/IP multicast as the underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource- constrained networks. The most common of such use cases are also discussed. This document replaces [RFC7390] and updates [RFC7252] and [RFC7641].
Work in Progress
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time. There is work in progress to resolve some of the transfer layer issues by using a more RESTful approach. Please see https://github.com/core-wg/pubsub/blob/master/proposal.txt
Work in Progress
The Constrained RESTful Application Language (CoRAL)
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata.
Work in Progress
CoAP: Echo, Request-Tag, and Token Processing
This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address; it is now the recommeded way to mitigate amplification attacks. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security.
Work in Progress
Group OSCORE - Secure Group Communication for CoAP
This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. using IP multicast. In particular, the described approach defines how OSCORE should be used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and the corresponding CoAP responses.
Work in Progress
CoRE Resource Directory
In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined.
Work in Progress
FETCH & PATCH with Sensor Measurement Lists (SenML)
The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The CoAP FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the SenML data model.
Work in Progress
Additional Units for SenML
The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry.
Work in Progress
Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323.
Work in Progress
CBOR Encoding of Data Modeled with YANG
This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output, notifications and yang data template defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049].
Work in Progress
Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification
This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- channel) Please update TBD/TBD1/TBD2 statements with the assignments made by IANA to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG modules.
Work in Progress
Constrained RESTful Environments (CoRE) Link Format
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]
The Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.
CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.
Group Communication for the Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.
Observing Resources in the Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.
The YANG 1.1 Data Modeling Language
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
Block-Wise Transfers in the Constrained Application Protocol (CoAP)
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.
PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)
The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.
This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.
Sensor Measurement Lists (SenML)
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
Object Security for Constrained RESTful Environments (OSCORE)
This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.
Constrained Application Protocol (CoAP) Hop-Limit Option
The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.
Acknowledgements
Marco Tiloca provided comments on a draft of this document.
Authors' Addresses
Universitaet Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
Ericsson
jaime.jimenez@ericsson.com