Constrained Application Protocol

Constrained Application Protocol (CoAP) is a specialized Internet Application Protocol for constrained devices, as defined in RFC 7252. It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols. CoAP is designed for use between devices on the same constrained network (e.g., low-power, lossy networks), between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.

CoAP is a service layer protocol that is intended for use in resource-constrained internet devices, such as wireless sensor network nodes. CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity.[1][2] Multicast, low overhead, and simplicity are extremely important for Internet of Things (IoT) and Machine-to-Machine (M2M) devices, which tend to be deeply embedded and have much less memory and power supply than traditional internet devices have. Therefore, efficiency is very important. CoAP can run on most devices that support UDP or a UDP analogue.

The Internet Engineering Task Force (IETF) Constrained RESTful Environments Working Group (CoRE) has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functions have been added. The core of the protocol is specified in RFC 7252; important extensions are in various stages of the standardization process.

FeaturesEdit

Message formatsEdit

The smallest CoAP message is 4 bytes in length, if omitting Token, Options and Payload. CoAP makes use of two message types, requests and responses, using a simple, binary, base header format. The base header may be followed by options in an optimized Type-Length-Value format. CoAP is by default bound to UDP and optionally to DTLS, providing a high level of communications security.

Any bytes after the headers in the packet are considered the message body. The length of the message body is implied by the datagram length. 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.

CoAP Header
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
4 32 VER Type Token Length Request/Response Code Message ID
8 64 Token (0 - 8 bytes)
12 96
16 128 Options (If Available)
20 160 1 1 1 1 1 1 1 1 Payload (If Available)

CoAP Fixed Header: Version, Type, Token Length, Request/Response Code and Message ID.Edit

The first 4 bytes are mandatory in all CoAP datagrams.

These fields can be easily extracted from these 4 bytes in C via these macros:

#define COAP_HEADER_VERSION(data)  ( (0xC0 & data[0])>>6    )
#define COAP_HEADER_TYPE(data)     ( (0x30 & data[0])>>4    )
#define COAP_HEADER_TKL(data)      ( (0x0F & data[0])>>0    )
#define COAP_HEADER_CLASS(data)    ( ((data[1]>>5)&0x07)    )
#define COAP_HEADER_CODE(data)     ( ((data[1]>>0)&0x1F)    )
#define COAP_HEADER_MID(data)      ( (data[2]<<8)|(data[3]) )

Version (VER) (2 bits)Edit

Indicates the CoAP version number.

Type (2 bits)Edit

This describes the datagram's message type for the two message type context of Request and Response.
  • Request
    • 0 : Confirmable : This message expects a corresponding Acknowledgement message.
    • 1 : Non-confirmable : This message does not expect a confirmation message.
  • Response
    • 2 : Acknowledgement : This message is a response that acknowledge a confirmable message
    • 3 : Reset : This message indicates that it had received a message but could not process it.

Token Length (4 bits)Edit

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

Request/Response Code (8 bits)Edit

0 1 2 3 4 5 6 7
Class Code

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:

    1. Method: 0.XX
      1. EMPTY
      2. GET
      3. POST
      4. PUT
      5. DELETE
      6. FETCH
      7. PATCH
      8. iPATCH
    2. Success: 2.XX
      1. Created
      2. Deleted
      3. Valid
      4. Changed
      5. Content
      6. Continue
      1. Client Error: 4.XX
        1. Bad Request
        2. Unauthorized
        3. Bad Option
        4. Forbidden
        5. Not Found
        6. Method Not Allowed
        7. Not Acceptable
        8. Request Entity Incomplete
        9. Conflict
        10. Precondition Failed
        11. Request Entity Too Large
        12. Unsupported Content-Format
        1. Server Error: 5.XX
          1. Internal Server Error
          2. Not Implemented
          3. Bad Gateway
          4. Service Unavailable
          5. Gateway Timeout
          6. Proxying Not Supported
        2. Signaling Codes: 7.XX
          1. Unassigned
          2. CSM
          3. Ping
          4. Pong
          5. Release
          6. Abort

        Message ID (16 bits)Edit

        Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.:Response messages will have the same Message ID as request.

        TokenEdit

        Optional field whose size is indicated by the Token Length field, whose values is generated by the client. The server must echo every token value without any modification back to the client. It is intended for use as a client-local identifier to provide extra context for certain concurrent transactions.

        OptionEdit

        Option Format
        Bit Positions
        0 1 2 3 4 5 6 7
        Option Delta Option Length
        Option Delta Extended (None, 8bit, 16bits)
        Option Length Extended (None, 8bit, 16bits)
        Option Value

        Option Delta:

        • 0 to 12 : For delta between 0 to 12 : Small delta between the last option id and the desired option id
        • 13 : For delta from 13 to 268 : Option Delta Extended is 8bit that is the Option Delta value minus 13
        • 14 : For delta from 269 to 65,804 : Option Delta Extended is 16bit that is the Option Delta value minus 269
        • 15 : Reserved for Payload Marker, where the Options Delta/length are set together as 0xFF.

        Option Length:

        • 0 to 12 : For Option Length between 0 to 12 : Small Option Length between the last option id and the desired option id
        • 13 : For Option Length from 13 to 268 : Option Length Extended is 8bit that is the Option Length value minus 13
        • 14 : For Option Length from 269 to 65,804 : Option Length Extended is 16bit that is the Option Length value minus 269
        • 15 : Reserved for future use. Is an error if Option Delta field is set to 0xFF.

        Option Value:

        • Size of Option Value field is defined by Option Length value in bytes.
        • Semantic and format this field depends on the respective option.

        ImplementationsEdit

        Name Programming Language Implemented CoAP version Client/Server Implemented CoAP features License Link
        aiocoap Python 3 RFC 7252 Client + Server Blockwise Transfers, Observe (partial) MIT https://pypi.python.org/pypi/aiocoap
        Californium Java RFC 7252 Client + Server Observe, Blockwise Transfers, DTLS EPL+EDL https://www.eclipse.org/californium
        cantcoap C++/C RFC 7252 Client + Server BSD https://github.com/staropram/cantcoap
        Canopus Go RFC 7252 Client + Server Core Apache License 2.0 https://github.com/zubairhamed/canopus
        Go-CoAP Go RFC 7252, RFC 8232, RFC 7641, RFC 7959 Client + Server Core, Observe, Blockwise, Multicast, TCP/TLS Apache License 2.0 https://github.com/go-ocf/go-coap
        CoAP implementation for Go Go RFC 7252 Client + Server Core + Draft Subscribe MIT https://github.com/dustin/go-coap
        CoAP.NET C# RFC 7252, coap-13, coap-08, coap-03 Client + Server Core, Observe, Blockwise Transfers 3-clause BSD https://github.com/smeshlink/CoAP.NET
        CoAPSharp C#, .NET RFC 7252 Client + Server Core, Observe, Block, RD LGPL http://www.coapsharp.com
        CoAPthon Python RFC 7252 Client + Server + Forward Proxy + Reverse Proxy Observe, Multicast server discovery, CoRE Link Format parsing, Block-wise MIT https://github.com/Tanganelli/CoAPthon
        CoAP Shell Java RFC 7252 Client Observe, Blockwise Transfers, DTLS Apache License 2.0 https://github.com/tzolov/coap-shell
        Copper JavaScript (Browser Plugin) RFC 7252 Client Observe, Blockwise Transfers 3-clause BSD https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/[permanent dead link]
        eCoAP C RFC 7252 Client + Server Core MIT https://gitlab.com/jobol/ecoap
        Erbium for Contiki C RFC 7252 Client + Server Observe, Blockwise Transfers 3-clause BSD http://www.contiki-os.org/ (er-rest-example)
        iCoAP Objective-C RFC 7252 Client Core, Observe, Blockwise Transfers MIT https://github.com/stuffrabbit/iCoAP
        jCoAP Java RFC 7252 Client + Server Observe, Blockwise Transfers Apache License 2.0 https://code.google.com/p/jcoap/
        libcoap C RFC 7252 Client + Server Observe, Blockwise Transfers, DTLS BSD/GPL https://github.com/obgm/libcoap
        LibNyoci C RFC 7252 Client + Server Core, Observe, Block, DTLS MIT https://github.com/darconeous/libnyoci
        lobaro-coap C RFC 7252 Client + Server Observe, Blockwise Transfers MIT http://www.lobaro.com/lobaro-coap
        microcoap C RFC 7252 Client + Server MIT https://github.com/1248/microcoap
        microCoAPy MicroPython RFC 7252 Client + Server Core Apache License 2.0 https://github.com/insighio/microCoAPy
        nanocoap C RFC 7252 Client + Server Core, Blockwise Transfers LGPL https://api.riot-os.org/group__net__nanocoap.html
        nCoap Java RFC 7252 Client + Server Observe, Blockwise Transfers, CoRE Link Format, Endpoint-ID-Draft BSD https://github.com/okleine/nCoAP
        node-coap Javascript RFC 7252 Client + Server Core, Observe, Block MIT https://github.com/mcollina/node-coap
        Ruby coap Ruby RFC 7252 Client + Server (david) Core, Observe, Block, RD MIT, GPL https://github.com/nning/coap
        https://github.com/nning/david
        Sensinode C Device Library C RFC 7252 Client + Server Core, Observe, Block, RD Commercial https://silver.arm.com/browse/SEN00
        Sensinode Java Device Library Java SE RFC 7252 Client + Server Core, Observe, Block, RD Commercial https://silver.arm.com/browse/SEN00
        Sensinode NanoService Platform Java SE RFC 7252 Cloud Server Core, Observe, Block, RD Commercial https://silver.arm.com/browse/SEN00
        SwiftCoAP Swift RFC 7252 Client + Server Core, Observe, Blockwise Transfers MIT https://github.com/stuffrabbit/SwiftCoAP
        TinyOS CoapBlip nesC/C coap-13 Client + Server Observe, Blockwise Transfers BSD https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP
        txThings Python (Twisted) RFC 7252 Client + Server Blockwise Transfers, Observe (partial) MIT https://github.com/mwasilak/txThings/
        FreeCoAP C RFC 7252 Client + Server + HTTP/CoAP Proxy Core, DTLS, Blockwise Transfers BSD https://github.com/keith-cullen/FreeCoAP
        coap-rs Rust RFC 7252 Client + Server MIT https://github.com/Covertness/coap-rs
        YaCoAP C MIT https://github.com/RIOT-Makers/YaCoAP

        Proxy implementationsEdit

        CoAP group communicationEdit

        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 7390[3] 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]

        SecurityEdit

        CoAP defines four security modes[5]

        • NoSec, where DTLS is disabled
        • PreSharedKey, where DTLS is enabled, there is a list of pre-shared keys, and each key includes a list of which nodes it can be used to communicate with. Devices must support the AES cipher suite.
        • RawPublicKey, where DTLS is enabled and the device uses an asymmetric key pair without a certificate, which is validated out of band. Devices must support the AES cipher suite and Elliptic Curve algorithms for key exchange.
        • Certificate, where DTLS is enabled and the device uses X.509 certificates for validation.

        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]

        Security issuesEdit

        Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks[7], these provisions are not implemented in practice[8], resulting in the presence of over 580,000 targets primarily located in China and attacks up to 320Gbps[9].

        See alsoEdit

        ReferencesEdit

        1. ^ RFC 7252, Constrained Application Protocol (CoAP)
        2. ^ "Integrating Wireless Sensor Networks with the Web" , Walter, Colitti 2011
        3. ^ RFC 7390, Group Communication for CoAP
        4. ^ "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
        5. ^ RFC 7252, Constrained Application Protocol (CoAP)
        6. ^ Capossele, Angelo; Cervo, Valerio; De Cicco, Gianluca; Petrioli, Chiara (June 2015). "Security as a CoAP resource: An optimized DTLS implementation for the IoT". IEEE: 529–554. doi:10.1109/ICC.2015.7248379.
        7. ^ "TLS 1.3 is going to save us all, and other reasons why IoT is still insecure", Dani Grant, 2017-12-24
        8. ^ "When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols", Federico Maggi and Rainer Vosseler, 2018-12-06
        9. ^ "The CoAP protocol is the next big thing for DDoS attacks", Catalin Cimpanu, 2018-12-05

        External linksEdit