The Constrained Application Protocol [57] is a web application layer protocol de-signed for use with resource constrained nodes and constrained networks in M2M applications. CoAP enables a request/response model of communication, similar to HTTP, including features such as URIs and support for different media types.
The standard, defined in the RFC7252, is specifically designed to be operate over
datagram transports, mainly UDP. This is a key underlying difference to HTTP, which operates over a connection-based protocol such as TCP. CoAP can be used with DTLS to allow secure communication over UDP, and also used over other transports such as SMS, TCP and SCTP [57].
The fundamentals of CoAP consist of the messaging model, and the request/response model. The messaging models concern is exchanging messages over UDP between endpoints, and does not define servers or clients. The request/response model defines how a server and a client interact with each other. We will examine the messaging model first.
The CoAP messaging model has two features:
• Stop-and-wait retransmission reliability with exponential back-off for Confirm-able messages.
• Duplicate detection for both Confirmable and Non-Confirmable messages.
CoAP defines four types of messages: Confirmable (CON), Non-Confirmable (NON), Acknowledgement (ACK) and Reset (RST). The Confirmable message type is used for reliably transmitted messages. The recipient of such a message must either respond with an ACK (to acknowledge) or a RST (to indicate that the message could not be processed properly). A NON message is a one-way message, and if a message does not make it to the recipient, neither the sender nor the receiver will know without using out-of-band data.
CoAP requests and responses are carried in CoAP messages, and include either a Method Code or a Response Code, respectively. The Method Codes are listed in table 6. The Methods map roughly to HTTP methods, but are specifically defined for CoAP. Response Codes belong to class 2, 4 or 5, indicating Success, Client Error and Server Error, respectively. Response Codes are written in the formatC.XX, with Cas Class of code, and XX specifying the details of the response code.
CoAP also specifies how the message type influences client and server interaction. A CON request requires an ACK within ACK_TIMEOUT, which is by default 2 seconds.
Since replying with an ACK and immediately sending the actual response to the request would be wasteful, CoAP specifies that responses may be sent within the same PDU (Protocol Data Unit) as an ACK. An example of this kind of exchange is shown in figure 7. The optimization, called piggybacking, allows a request and response pair to occupy only two PDUs. In case either of the messages are lost,
Method Short Description Safe Idempotent GET Retrieves a represetation of the
inform-ation that correspond to the resource identied in the request URI.
Yes Yes
POST A request to process the enclosed data. - -PUT A request to create or update the
re-source with the enclosed representa-tion.
- Yes
DELETE A request to delete the resource at the
URI. - Yes
Table 6: List of CoAP Methods. Safe methods do not alter server state.
the standard retransmission scheme for CoAP is used until the client receives the piggybacked response. [57]
If the client is under a limitation to only send one message to the server, but would still like to receive a response, the request may be made with a NON message.
In this case the response is also sent using a NON message. This scenario could occur if for example a cellular NB-IoT device must conserve power, and uplink transmissions consume significantly more power than receiving. When compared to a CON request, the client does lose the information on whether the request or the response was lost in transit, but gains more control over it’s own power consumption.
This could be very significant for the end-nodes battery life when it is experiencing a very lossy network.
Client Server
POST, CON 2.04 Changed, ACK
Figure 7: A Confirmable request which receives a response piggy-backed to an ACK message.
CoAP options represent optional or default request and response information, and some options provide similar functionality to what HTTP headers provide. Ex-amples of CoAP options include payload content-types and accepted content-types.
CoAP URIs paths are also encoded as options. [57]
Client Server POST, NON
2.04 Changed, NON
Figure 8: A Non-Confirmable request which receives a NON response.
As CoAP is designed for constrained networks, it provides an option for the client to request that no response is sent back to it. The No-Response option, specified in RFC 7967 allows the client to specify for which response classes it does not request a response. If all response classes are not requested, the client should cease listening for any responses to the specific request. If there is only one request active, the client no longer has any obligations to the server, thus the communication is entirely one-way. [58]
An example of communication between a CoAP client and server that implement theNo-Response option is shown in figure9. Use of the option enables lower power consumption for IP connected radio end-node, but makes it impossible for the client to know the result of its request, or if it was received by the server. This CoAP option also makes it possible for IP-connected battery powered NB-IoT end-nodes to implement identical request/response patterns as in LoRaWAN and Sigfox.
Client Server
POST, NON
Figure 9: A Non-Confirmable request using the No-Response option to display disinterest in any response.
2.8.1 OSCORE
Object Security for Constrained RESTful Environments (OSCORE) is an application-layer method with the objective of securing CoAP data between endpoints. The method is an implementation of the RFCs Concise Binary Object Representation (CBOR) and CBOR object Signing and Encryption (COSE) for use only with CoAP. OSCORE is currently available as the IETF draft titled draft-ietf-core-object-security-15. [59]
OSCORE is implemented with pre-shared keys, and is secured to the extent that still allows CoAP proxies to function. OSCOREs properties guarantee end-to-end en-cryption, integrity, replay protection, and binding of response to request. It secures the request method, the requested resource and the message payload but does not protect the CoAP messaging layer or the CoAP Token. It supports the No-Response CoAP option among other options of CoAP. [59]
In their comparison of OSCORE and different DTLS, TLS versions, J. Mattson et al.
[60] found that of the UDP protocols, DTLS 1.2 has a notably higher overhead com-pared to DTLS 1.3 and OSCORE. DTLS 1.3 overhead was slightly larger than that of OSCORE, and similar when using theshort header formatof DTLS 1.3. However, the short header format can only be used once the DTLS handshake is complete [40], so it is not of use in cases when the session only lasts one request/response pair.