CoAP - IoT protocol for resource-constrained devices

CoAP (Constrained Application Protocol) is an application layer protocol designed specifically for devices with limited computational resources, memory, and energy - microcontrollers with a few kilobytes of RAM, battery-powered sensors, and low-bandwidth networks (6LoWPAN, NB-IoT, LoRaWAN). Defined in RFC 7252 (2014) by the IETF, CoAP can be described as “HTTP for IoT” - it implements a RESTful model (GET, PUT, POST, DELETE) over UDP instead of TCP, requiring minimal resources and handling networks with high packet loss.

CoAP is widely used in smart city systems, environmental monitoring, smart buildings, and industrial sensor networks - wherever HTTP and TCP are too heavy for end devices.

Protocol architecture

CoAP operates in a client-server model (like HTTP), but with significant differences arising from the constraints of the target environment:

Parameter	CoAP	CoAP over DTLS
Transport	UDP	UDP + DTLS 1.2/1.3
Port	5683	5684
Authentication	No native	PSK, X.509 certificates, RPK
Encryption	None	AES-CCM-128 (DTLS)
Communication model	Request/response + observe	Same
Header size	4 bytes (compact binary)	+ DTLS overhead
Resource discovery	/.well-known/core (RFC 6690)	Same

Key CoAP features:

• Observe (RFC 7641) - a client registers for notifications about resource changes, eliminating the need for polling. The server sends updates when the value changes
• Block-wise transfer (RFC 7959) - transmitting large payloads in blocks, necessary with the limited MTU of 6LoWPAN networks (127 bytes per IEEE 802.15.4 frame)
• Resource discovery - the /.well-known/core endpoint returns a list of all device resources in CoRE Link Format
• Proxy and cache - CoAP supports HTTP-CoAP proxying, enabling integration of IoT devices with web infrastructure

Applications

CoAP is used primarily in environments where HTTP/TCP is not an option:

• 6LoWPAN/Thread sensor networks - monitoring temperature, humidity, and air quality in buildings and production halls
• Smart metering - reading smart meters over NB-IoT with minimal energy consumption
• Building automation - controlling lighting and HVAC through mesh protocols (Thread, Zigbee with CoAP gateway)
• Industrial asset monitoring - vibration and temperature sensors on machinery, reporting via CoAP to an IoT gateway

Security assessment

CoAP itself does not provide security - DTLS is optional and in practice often omitted due to the resource constraints of target devices.

Protocol and typical deployment vulnerabilities:

• DTLS optional - the specification defines four security modes, including “NoSec” (no security). Many implementations default to operating without DTLS due to the computational cost of the handshake on Cortex-M0 class microcontrollers
• UDP amplification - CoAP over UDP is susceptible to amplification attacks (reflected DDoS). An attacker sends a query with a spoofed source address, and the device responds with a larger packet to the victim
• Resource discovery - the /.well-known/core endpoint reveals device resource structure without authentication
• No authorization - even with DTLS (authentication + encryption), CoAP does not define an authorization model - an authenticated client has access to all resources
• Observe flooding - an attacker can register observation of many resources, generating a continuous stream of notifications that overloads resource-constrained devices

OSCORE (RFC 8613) is a newer security mechanism - it secures CoAP payloads at the application layer (end-to-end), unlike DTLS, which only protects the hop-by-hop connection. OSCORE is lighter than DTLS and works through proxies, but its adoption is still at an early stage.

Segmentation and protection

CoAP devices are typically the simplest and weakest links in the IoT network - microcontrollers with no ability to run a security agent, often with firmware that is rarely or never updated. Network segmentation is their primary (and often only) protection mechanism.

Segmentation principles for CoAP networks:

1. IoT gateway as zone boundary - CoAP devices should not communicate directly with the IT network or cloud. A gateway translates CoAP to HTTPS/MQTT and serves as a control point
2. Sensor network microsegmentation - separate subnets for sensors with different functions (environmental monitoring vs. process control)
3. Gateway-level filtering - the gateway should pass only defined methods (GET, PUT) on defined resources and block discovery from outside
4. Rate limiting - limiting the frequency of queries to CoAP devices protects against device resource exhaustion and amplification attacks
5. Anomaly monitoring - detecting unusual communication patterns (new query sources, mass observe registrations)

A detailed approach to designing security zones in OT and IoT networks is described in our article on OT network segmentation.

Sources

• RFC 7252 - The Constrained Application Protocol - CoAP specification
• RFC 7641 - Observing Resources in CoAP - observe mechanism
• RFC 8613 - Object Security for Constrained RESTful Environments (OSCORE) - application layer security
• NIST SP 800-183 - Networks of Things
• ENISA Baseline Security Recommendations for IoT - European IoT security guidelines