A TCP and TLS Transport for the Constrained Application Protocol (CoAP)

The Internet protocol stack is organized in layers, namely data link layer, network layer, transport layer, and the application layer. IP emerged as the waist of the hour glass and supports a variety of link layers and new link layer technologies can be added in the future, without affecting IP. Combined with the end-to-end principle the hour glass indicates the level of protocol understanding intermediaries need to have in order to exchange forward IP packets between a sender and a receiver (absent any specific application layer entities, like proxies or caches). Having IP as the waist meant that anyone could extend the layers above the network layer in the way they wanted to communicate end-to-end, including defining new transport layer protocols (as it was done with SCTP, and DCCP). Unfortunately, deployments departed from this ideal architecture. When the Constrained Application Protocol (CoAP) was designed it was assumed that many Internet of Things deployments would be clean-slate. Today, we know that some deployments have to integrate well with existing enterprise infrastructure, where the use of UDP-based protocols is not well-received and firewalling use is very common. To make IoT devices work smoothly in these demanding environments CoAP has to make use of a different transport protocol, namely TCP and in some situations even TLS . This document describes a shim header that conveys length information about the included payload. Modifications to CoAP are intentially avoided (e.g, to introduce optimizations).

The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

This specification defines a simple layer necessary to convey length information about the exchange payloads in a 32-bit length field indicating the number of bytes in the payload following that header.

The use of CoAP over a transport protocol offering reliable transmission already offers functionality that could be offered by CoAP itself. While a developer can re-use an already existing CoAP protocol stack, the use of TCP makes some CoAP features redundant. Section 4.2 of discusses the ability to convey messages in CoAP reliably as a "confirmable message", which always generates a response. It can be used without harm but does not add any value since all messages would be transmitted reliably already thanks to the features offered by TCP. A developer writing an application that runs CoAP over TCP or CoAP over TLS needs to be mindful about the changed semantic of CoAP. For example, the marking the message as non-confirmable (see Section 4.3 of ) does not make the transmission unreliable but it instead saves the transmission of one CoAP message.

This document defines how to convey CoAP over TCP and TLS. It does not introduce new vulnerabilities beyond those described already in the CoAP specification. When CoAP is exchanged over TLS port 443 then the "TLS Application Layer Protocol Negotiation Extension" MUST be used to allow demultiplexing at the server-side unless out-of-band information ensures that the client only interacts with a server that is able to demultiplex CoAP messages over port 443. This would, for example, be true for many Internet of Things deployments where clients are pre-configured to only ever talk with specific servers. When CoAP over TLS is used then the use of the shim header that includes the length information is redundant since the TLS protocol headers already include length information. As such, the length header MUST be omitted when CoAP is exchanged over TLS.

This document requests a value from the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created by : CoAP 0x63 0x6f 0x61 0x70 ("coap") This document.

We would like to thank Michael Koster, Zach Shelby, and Szymon Sasin for their feedback.