19 CoAP Security: Implementation and Operations

A CoAP failure needs a diagnosis at the boundary where the observed behavior stops matching the request. A timeout can involve packet loss, acknowledgement behavior, or an unavailable endpoint rather than a wrong resource path. A failed DTLS handshake instead calls for key or certificate checks before resource handling can succeed. Response codes then distinguish a missing resource from a method that the resource does not support.

• Request times out: UDP packet loss or no ACK. Increase retransmission timeout, use CON messages instead of NON, and check network quality.
• Confirmable message never acknowledged: Server down or wrong endpoint. Verify the server is running and confirm the CoAP URI format coap://host:port/path.
• Block transfer fails mid-stream: MTU too large or packet fragmentation. Reduce block size from 1024 bytes to 512 or 256 and check network MTU settings.
• Observe notifications stop: Server crashed or network partition. Re-establish the observe relationship and add client-side timeout detection.
• Multicast discovery finds no devices: Wrong multicast address or routing. Use FF02::FD for link-local or FF05::FD for site-local and check IPv6 multicast routing.
• DTLS handshake fails: PSK mismatch or certificate error. Verify pre-shared keys match exactly and check certificate validity for certificate mode.
• Response code 4.04 Not Found: Wrong resource path. Check URI case sensitivity and verify the resource exists on the server.
• Response code 4.05 Method Not Allowed: Unsupported method on the resource. Confirm that the resource supports GET, POST, PUT, or DELETE as expected.

Debug Checklist:

• Connection and Discovery Issues:

  • Verify server is reachable on UDP port 5683 (or 5684 for DTLS)
  • Test with ping to confirm basic network connectivity
  • Check firewall allows UDP traffic on CoAP port
  • For multicast: verify IPv6 multicast is enabled on network interface
  • Use CoAP client tool to test server response (e.g., coap-client, libcoap)

• Request/Response Problems:

  • Confirm CoAP URI format: coap://server-ip:5683/resource/path
  • Check message type (CON requires ACK, NON does not)
  • Verify token in response matches token in request
  • Review response code (2.xx success, 4.xx client error, 5.xx server error)
  • Monitor retransmission attempts (exponential backoff 2s, 4s, 8s, 16s)

• Observe and Block Transfer Issues:

  • For Observe: confirm observe option set in request (observe=0)
  • Check server sends notifications with observe option and increasing sequence numbers
  • For Block transfers: verify block size negotiation (Block1/Block2 options)
  • Monitor block number sequence (must be consecutive)
  • Test smaller block sizes if large transfers fail

Read these points as one sequence: start with Performance and Reliability; then measure UDP packet loss and its effect on CoAP retries and latency; then check network latency, server capacity, deduplication, and congestion.

• Performance and Reliability:

  • Measure UDP packet loss and whether it causes unacceptable CoAP retries or delay for this workload.
  • Monitor network latency (affects retransmission timing)
  • Verify server can handle request rate (no overload)
  • Review message deduplication (servers drop duplicate message IDs)
  • Check for network congestion (CoAP includes congestion control)

• Security (DTLS) Issues:

  • Verify DTLS version compatibility (DTLSv1.2 recommended)
  • Check pre-shared key encoding (must be exact byte match)
  • For certificates: verify CA chain and server certificate validity
  • Monitor DTLS session timeouts and renegotiation
  • Test with plain CoAP first, then add DTLS layer

Common Error Codes:

• 2.01 Created: Resource successfully created (POST response)
• 2.02 Deleted: Resource successfully deleted
• 2.03 Valid: Resource still valid (cache validation)
• 2.04 Changed: Resource successfully updated (PUT response)
• 2.05 Content: Resource content returned (GET response)
• 4.00 Bad Request: Malformed request or invalid options
• 4.01 Unauthorized: Authentication required or failed
• 4.04 Not Found: Resource does not exist
• 4.05 Method Not Allowed: HTTP method not supported on resource
• 5.00 Internal Server Error: Server encountered error processing request
• 5.03 Service Unavailable: Server temporarily unable to handle request

Tools for Debugging:

• libcoap tools: coap-client and coap-server for testing
• Copper (Cu): Firefox/Chrome plugin for CoAP browsing (deprecated but useful)
• Wireshark: CoAP dissector for packet analysis (filter: coap)
• tcpdump: Capture UDP packets (tcpdump -i any port 5683 -vv)
• Eclipse Californium: Java-based CoAP library with extensive logging
• aiocoap: Python library with good debugging output

A CoAP payload that works on local Wi-Fi can fail on a constrained network when its transfer exceeds the available packet budget. Fragment loss can prevent the receiver from reconstructing the complete message even though other fragments arrived. Block-wise transfer supports larger configurations, firmware, and files without treating them as one oversized payload. The acceptance test must use the actual constrained path because Wi-Fi success does not establish that path’s behavior.

The mistake: Sending CoAP payloads larger than the network MTU (typically 1280 bytes for IPv6, often much smaller for constrained networks like 6LoWPAN with 127-byte frames), causing silent packet drops or fragmentation failures.

Symptoms:

• Large GET responses never arrive at the client
• PUT/POST requests with substantial payloads fail intermittently
• Works on local Wi-Fi but fails over 6LoWPAN or constrained networks
• Wireshark shows fragmented packets but no reassembled response

Why it happens: CoAP runs over UDP, which doesn’t handle fragmentation gracefully:

• IPv6 minimum MTU: 1280 bytes, but CoAP payload should be much smaller
• 6LoWPAN frame: 127 bytes maximum, ~80 bytes after headers
• UDP fragmentation: If any fragment is lost, entire message is lost
• No automatic retransmission of individual fragments

The fix:

# Use CoAP Block-wise Transfer (RFC 7959) for large payloads
from aiocoap import Message, Context
from aiocoap.numbers.codes import GET

async def get_large_resource(uri):
    context = await Context.create_client_context()

    # Request with Block2 option - library handles chunking
    request = Message(code=GET, uri=uri)
    # Block size: 64 bytes (szx=2), 128 bytes (szx=3), 256 bytes (szx=4)
    # Smaller blocks = more round trips but works on constrained networks

    response = await context.request(request).response
    return response.payload  # Library reassembles blocks automatically

// Embedded C: Check payload size before sending
#define COAP_MAX_PAYLOAD_6LOWPAN  64   // Safe for 802.15.4
#define COAP_MAX_PAYLOAD_UDP      1024 // Safe for most networks

size_t max_payload = is_constrained_network() ?
    COAP_MAX_PAYLOAD_6LOWPAN : COAP_MAX_PAYLOAD_UDP;

if (payload_len > max_payload) {
    // Use Block1 (request) or Block2 (response) transfer
    return coap_send_blockwise(payload, payload_len, max_payload);
}

Prevention: Design payloads to fit in 64-128 bytes for 6LoWPAN networks. Use Block-wise Transfer for firmware updates, large configurations, or file downloads. Test on the actual constrained network, not just Wi-Fi.

A battery sensor needs different exchange policies for routine measurements and important control messages. Repeated confirmable exchanges add acknowledgements and retry work that may be unnecessary when the next reading replaces a missed one. Non-confirmable delivery does not supply the failure-detection behavior required by the command path in this example. A hybrid policy ties confirmation to message importance instead of treating telemetry, alarms, and device commands as equivalent.

The mistake: Using Confirmable (CON) messages for all communications because “reliability is important,” leading to excessive battery drain and network congestion, or using Non-Confirmable (NON) for critical commands where delivery must be guaranteed.

Symptoms:

• Battery-powered sensors lasting weeks instead of years
• Unnecessary retransmission storms when network is lossy
• Commands occasionally not reaching actuators (lights, locks)
• High latency due to waiting for ACKs on every message

Why it happens: Developers often misunderstand the trade-offs:

• CON overuse: HTTP background makes developers expect reliability for everything
• NON overuse: Trying to maximize battery life without considering message importance
• No hybrid strategy: Treating all messages the same regardless of criticality

The fix:

from aiocoap import Message, Context
from aiocoap.numbers.codes import GET, PUT
from aiocoap.numbers.types import CON, NON

# NON for periodic telemetry (loss acceptable, battery critical)
async def send_temperature_reading(temp):
    request = Message(
        code=PUT,
        mtype=NON,  # Fire-and-forget, ~5x better battery life
        uri='coap://server/sensors/temp',
        payload=f'{temp}'.encode()
    )
    await context.request(request).response

# CON for critical commands (must know if it worked)
async def unlock_door():
    request = Message(
        code=PUT,
        mtype=CON,  # Need acknowledgment for security
        uri='coap://door/lock',
        payload=b'unlock'
    )
    try:
        response = await context.request(request).response
        return response.code.is_successful()
    except Exception:
        return False  # Command failed, alert user

# CON for configuration changes (must be applied)
async def update_reporting_interval(seconds):
    request = Message(
        code=PUT,
        mtype=CON,  # Config must be confirmed
        uri='coap://sensor/config/interval',
        payload=str(seconds).encode()
    )
    return await context.request(request).response

Decision matrix:

• Periodic sensor readings: Use NON for routine telemetry; do not use CON.
• Alert or alarm notifications: Use CON so the receiver must acknowledge delivery.
• Device commands (on/off): Use CON because actuation commands need confirmation.
• Configuration updates: Use CON so applied settings are confirmed.
• Status queries: Depends on how critical the response is.
• Firmware chunks: Use CON with Block2 acknowledgements.

Prevention: Default to NON for periodic telemetry. Use CON only for commands, configurations, and alerts. Implement a message priority system that selects type based on criticality.