Constrained Application Protocol

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

Features

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

• Web protocol fulfilling M2M requirements in constrained environments
• UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
• Asynchronous message exchanges
• Low header overhead and parsing complexity
• URI and Content-type support
• Simple proxy and caching capabilities
• Stateless HTTP mapping
• Security binding to Datagram Transport Layer Security (DTLS)

The Protocol

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
|      Application     |
+----------------------+
+----------------------+  \
|  Requests/Responses  |  |
|----------------------|  | CoAP
|       Messages       |  |
+----------------------+  /
+----------------------+
|          UDP         |
+----------------------+

Message Format

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Ver| T |  TKL  |      Code     |          Message ID           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Token (if any, TKL bytes) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |1 1 1 1 1 1 1 1|    Payload (if any) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (Ver) (2 bits)

Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

Type (T) (2 bits)

Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

Token Length (TKL) (4 bits)

Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

CoAP Request/Response Code (8 bits)

Splits into a 3-bit class and 5-bit detail.

Message ID (16 bits)

Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

Security Considerations

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1. For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. RFC 7252 lists some things to avoid in implementation to reduce the risk and possibility of such attacks.

IP Address Spoofing

Cross-Protocol Attacks

Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

Implementations

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

Name	Programming Language	Client/Server	License	Link
Erbium for Contiki	C	Client + Server	3-clause BSD	http://www.contiki-os.org/
libcoap	C	Client + Server	BSD/GPL	https://libcoap.net/
Eclipse tinydtls	C	Client + Server	EPL+EDL	https://projects.eclipse.org/projects/iot.tinydtls
LibNyoci	C	Client + Server	MIT	https://github.com/darconeous/libnyoci
microcoap	C	Client + Server	MIT	https://github.com/1248/microcoap
cantcoap	C++/C	Client + Server	BSD	https://github.com/staropram/cantcoap
Lobaro CoAP	C	Client + Server	MIT	https://www.lobaro.com/portfolio/lobaro-coap/
MR-CoAP	Java		BSD	https://github.com/MR-CoAP/CoAP
Wakaama	C	Client + Server	EPL+EDL	https://www.eclipse.org/wakaama/index.html
coap-node	Javascript	Client	MIT	https://github.com/PeterEB/coap-node
coap-shepherd	Javascript	Server	MIT	https://github.com/PeterEB/coap-shepherd
Californium	Java	Client + Server	EPL+EDL	https://www.eclipse.org/californium
nCoap	Java	Client + Server	BSD	https://github.com/okleine/nCoAP
leshan	Java	Client + Server	EPL+EDL	https://github.com/eclipse/leshan
CoAP.NET	C#	Client + Server	3-clause BSD	https://github.com/smeshlink/CoAP.NET
CoAPSharp	C#, .NET	Client + Server	LGPL	http://www.coapsharp.com
Waher.Networking.CoAP	C#	Server		https://github.com/PeterWaher/IoTGateway
gen_coap	Erlang	Client + Server	MPL v1.1	https://github.com/gotthardp/gen_coap
go-coap	Go	Client + Server	MIT	https://github.com/go-ocf/go-coap
node-coap	Javascript	Client + Server	MIT	https://github.com/mcollina/node-coap
coap-cli	Javascript		MIT	https://github.com/mcollina/coap-cli
txThings	Python (Twisted)	Client + Server	MIT	https://github.com/mwasilak/txThings
aiocoap	Python 3	Client + Server	MIT	https://github.com/chrysn/aiocoap
CoAPthon	Python	Client + Server	MIT	https://github.com/Tanganelli/CoAPthon
Ruby coap	Ruby	Client	MIT	https://github.com/nning/coap
Ruby david	Ruby	Server	MIT	https://github.com/nning/david
coap-rs	Rust	Client + Server	MIT	https://github.com/Covertness/coap-rs
Copper	JavaScript (Browser Plugin)	Client	BSD	https://github.com/mkovatsc/Copper
iCoAP	Objective-C	Client	MIT	https://github.com/stuffrabbit/iCoAP
SwiftCoAP	Swift	Client + Server	MIT	https://github.com/stuffrabbit/SwiftCoAP
nCoap	Java	Client + Server	BSD	https://github.com/okleine/nCoAP
txThings	Python (Twisted)	Client + Server	MIT	https://github.com/mwasilak/txThings

Courses

• Vertiefendes Wahlfach-Projekt (2018)
• CoAP Chat Application for RIOT OS

References

• RFC 7252: https://tools.ietf.org/html/rfc7252
• CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
• Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/