Constrained Application Protocol (CoAP)
There are many wireless protocols (like IEEE 802.11 Series, 802.15 Series, Zigbee, etc) for communication between devices. However, considering a lot of small devices are unable to communicate efficiently with constrained resources, Internet Engineering Task Force (IETF) developed a lightweight protocol: Constrained Application Protocol (CoAP).
As many devices exist as components in vehicles and buildings with constrained resources, it leads to a lot of variation in power computing, communication bandwidth, etc. Thus CoAP is a specialized web transfer protocol for use with constrained nodes and constrained (e.g: low-power, lossy) networks.
With the completion of the CoAP specification, it is expected that there will be millions of devices deployed in various application domains in the future, CoAP would become the standard protocol to enable interaction between devices and to support IoT applications.
CoAP needs to consider optimizing the length of the datagram and satisfying the REST protocol to support URI (Uniform Resource Identifier). It also needs to provide dependable communication based on the UDP protocol.
Let us have a look at the features of CoAP:
- Web protocol used in M2M with constrained requirements
- Asynchronous message exchange
- Low overhead and very simple to parse
- URI and content-type support
- Proxy and caching capabilities
CoAP is based on REST architecture, which is a general design for accessing Internet resources. In order to overcome disadvantages in constrained resources, CoAP needs to optimize the length of the datagram and provide reliable communication. On one side, CoAP provides URI, REST methods such as GET, POST, PUT, and DELETE.
On the other side, based on lightweight UDP protocol, CoAP allows IP multicast, which satisfies group communication for IoT. To compensate for the unreliability of UDP, CoAP defines a retransmission mechanism and provides a resource discovery mechanism with the resource description.
CoAP interactive model is similar to HTTP's client-server model. Below is the abstract layer model of CoAP.
Abstract layer of COAP
The Message layer deals with UDP and with asynchronous messages. Message Layer supports 4 types of messages:
- 1.CON (confirmable)
- 2.NON (non-confirmable)
- 3.ACK (Acknowledgement)
- 4.RST (Reset)
There are two types of message transport:
- 1.Reliable message transport
- 2.Unreliable message transport
The Request/Response layer manages request/response interaction based on request/response messages. There are three ways in which the CoAP operates in request/response layer model:
- 1.Piggybacked
- 2.Separate response
- 3.Non confirmable request and response
CoAP is based on the exchange of compact messages that, by default, are transmitted over UDP (i.e. each CoAP message occupies the data section of one UDP datagram). The message of CoAP uses a simple binary format. Message= fixed-size 4-byte header plus a variable-length Token plus a sequence of CoAP options plus payload. The format is shown in the table below.
Where:
- Ver: It is a 2-bit unsigned integer indicating the version
- T: it is a 2-bit unsigned integer indicating the message type: 0 confirmable, 1 non-confirmable
- TKL: Token Length is the token 4-bit length
- Code: It is the code response (8-bit length)
- MessageID: It is the message ID expressed with 16-bit
- And so on ...
One of the important aspects when dealing with IoT protocols are security aspects. There are three main elements when considering security, namely integrity, authentication, and confidentiality. DTLS can achieve all of them. DTLS solves two problems: reordering and packet loss. It adds three implements:
- 1.packet retransmission
- 2.assigning sequence number within the handshake
- 3.replay detection.
Unlike network-layer security protocols, DTLS in application-layer protects end-to-end communication. No end-to-end communication protection will make it easy for an attacker to access to all text data that passes through a compromised node. DTLS also avoids cryptographic overhead problems that occur in lower-layer security protocols.
As stated before, CoAP uses UDP to transport information. CoAP relies on UDP security aspects to protect the information. As HTTP uses TLS over TCP, CoAP uses Datagram TLS over UDP. DTLS supports RSA, AES, and so on.
Anyway, we should consider that in some constrained devices some of DTLS cipher suits may not be available. It is important to notice that some cipher suites introduce some complexity and constrained devices may not have enough resources to manage it.
There are two layers in DTLS. The bottom one contains a Record protocol. The top one includes three protocols which are Alert, Handshake, and application data, in some condition Change Cipher Spec protocol may replace one of them. Change Cipher Spec message is used to notify Record protocol to protect subsequent records with just-negotiate cipher suite and keys.
Record protocol protects application data by using keys generated during Handshake. For outgoing messages, protocol divide, compress, encrypt and apply Message Authentication Code (MAC) to them. For incoming messages, protocol reassemble, decompress, decrypt and verify them.
Record header consists of two parts, one is the content type and another is the fragment field. Content-type decides what is contained in the fragment field. It could be alert protocol, Handshake protocol, or application data. Compare with DTLS Record, the Handshake protocol is rather a complex one, which involves a lot of exchange steps. Individual messages are grouped into message flights.
The figure below shows the process of Handshake.
Handshaking Process
A popular CoAP server is Mongoose which serves requests made using CoAP protocol.
Google Chrome does not support CoAP protocol hence one should use Mozilla Firefox to open Mongoose server and go through the documentation.