The core of the protocol is specified in RFC 7252. Various extensions have been proposed, particularly:
CoAP makes use of two message types, requests and responses, using a simple, binary header format. CoAP is by default bound to UDP and optionally to DTLS, providing a high level of communications security. When bound to UDP, the entire message must fit within a single datagram. When used with 6LoWPAN as defined in RFC 4944, messages should fit into a single IEEE 802.15.4 frame to minimize fragmentation.
The smallest CoAP message is 4 bytes in length, if the token, options and payload fields are omitted, i.e. if it only consists of the CoAP header. The header is followed by the token value (0 to 8 bytes) which may be followed by a list of options in an optimized type–length–value format. Any bytes after the header, token and options (if any) are considered the message payload, which is prefixed by the one-byte "payload marker" (0xFF). The length of the payload is implied by the datagram length.
The first 4 bytes are mandatory in all CoAP datagrams, they constitute the fixed-size header.
These fields can be extracted from these 4 bytes in C via these macros:
The three most significant bits form a number known as the "class", which is analogous to the class of HTTP status codes. The five least significant bits form a code that communicates further detail about the request or response. The entire code is typically communicated in the form class.code .
You can find the latest CoAP request/response codes at [1], though the below list gives some examples:
Every request carries a token (but it may be zero length) whose value was generated by the client. The server must echo every token value without any modification back to the client in the corresponding response. It is intended for use as a client-local identifier to match requests and responses, especially for concurrent requests.
Matching requests and responses is not done with the message ID because a response may be sent in a different message than the acknowledgement (which uses the message ID for matching). For example, this could be done to prevent retransmissions if obtaining the result takes some time. Such a detached response is called "separate response". In contrast, transmitting the response directly in the acknowledgement is called "piggybacked response" which is expected to be preferred for efficiency reasons.
Option delta:
Option length:
Option value:
RFC 7641, RFC 7959
https://docs.rs/coap/
There exist proxy implementations which provide forward or reverse proxy functionality for the CoAP protocol and also implementations which translate between protocols like HTTP and CoAP.
The following projects provide proxy functionality:
In many CoAP application domains it is essential to have the ability to address several CoAP resources as a group, instead of addressing each resource individually (e.g. to turn on all the CoAP-enabled lights in a room with a single CoAP request triggered by toggling the light switch). To address this need, the IETF has developed an optional extension for CoAP in the form of an experimental RFC: Group Communication for CoAP - RFC 73903 This extension relies on IP multicast to deliver the CoAP request to all group members. The use of multicast has certain benefits such as reducing the number of packets needed to deliver the request to the members. However, multicast also has its limitations such as poor reliability and being cache-unfriendly. An alternative method for CoAP group communication that uses unicasts instead of multicasts relies on having an intermediary where the groups are created. Clients send their group requests to the intermediary, which in turn sends individual unicast requests to the group members, collects the replies from them, and sends back an aggregated reply to the client.4
CoAP defines four security modes:5
Research has been conducted on optimizing DTLS by implementing security associates as CoAP resources rather than using DTLS as a security wrapper for CoAP traffic. This research has indicated that improvements of up to 6.5 times none optimized implementations.6
In addition to DTLS, RFC86137 defines the Object Security for Constrained RESTful Environments (OSCORE) protocol which provides security for CoAP at the application layer.
Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks,8 these provisions are not implemented in practice,9 resulting in the presence of over 580,000 targets primarily located in China and attacks up to 320 Gbit/s.10
RFC 7252, Constrained Application Protocol (CoAP) https://tools.ietf.org/html/rfc7252 ↩
"Integrating Wireless Sensor Networks with the Web Archived 2017-08-30 at the Wayback Machine" , Walter, Colitti 2011 http://hinrg.cs.jhu.edu/joomla/images/stories/IPSN_2011_koliti.pdf ↩
RFC 7390, Group Communication for CoAP https://tools.ietf.org/html/rfc7390 ↩
"Flexible Unicast-Based Group Communication for CoAP-Enabled Devices" , Ishaq, I.; Hoebeke, J.; Van den Abeele, F.; Rossey, J.; Moerman, I.; Demeester, P. Sensors 2014 http://www.mdpi.com/1424-8220/14/6/9833/htm ↩
Capossele, Angelo; Cervo, Valerio; De Cicco, Gianluca; Petrioli, Chiara (June 2015). "Security as a CoAP resource: An optimized DTLS implementation for the IoT". 2015 IEEE International Conference on Communications (ICC). pp. 529–554. doi:10.1109/ICC.2015.7248379. ISBN 978-1-4673-6432-4. S2CID 12568959. {{cite book}}: |journal= ignored (help) 978-1-4673-6432-4 ↩
Palombini, Francesca; Seitz, Ludwig; Selander, Goeran; Mattsson, John (2019). "Object Security for Constrained RESTful Environments (OSCORE)". tools.ietf.org. doi:10.17487/RFC8613. S2CID 58380874. Retrieved 2021-05-07. https://tools.ietf.org/html/rfc8613.html ↩
"TLS 1.3 is going to save us all, and other reasons why IoT is still insecure", Dani Grant, 2017-12-24 https://blog.cloudflare.com/why-iot-is-insecure/ ↩
"When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols", Federico Maggi and Rainer Vosseler, 2018-12-06 https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Maggi-When-Machines-Cant-Talk-wp.pdf ↩
"The CoAP protocol is the next big thing for DDoS attacks", Catalin Cimpanu, 2018-12-05 https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-ddos-attacks/ ↩