Draft: draft-ietf-core-coap-tcp-tls

Commentary: This is an extremely rough merge of core - coap - tcp - tls and core - coap - websockets . The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass . 
 With the merge of websockets-07 , the scope of coap - tcp - tls is extended to include CoAP over WebSockets . The draft title should reflect that change in scope . 
 I probably would stay explicit ( but then I 'm biased -- RFC 3095 :-) CoAP ( Constrained Application Protocol ) over TCP , TLS , and WebSockets 
 WFM . 
 Neglected to close with
The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
underlying transport protocol.  The Constrained Application Protocol
(CoAP), while inspired by HTTP, has been defined to make use of UDP
instead of TCP.  Therefore, reliable delivery and a simple congestion
control and flow control mechanism are provided by the message layer
of the CoAP protocol.
A number of environments benefit from the use of CoAP directly over a
reliable byte stream such as TCP, which already provides these
services.  This document defines the use of CoAP over TCP as well as
CoAP over TLS.
The RFC7252 was designed for Internet of Things (IoT) deployments,
assuming that UDP can be used unimpeded -- UDP RFC0768, or DTLS
RFC6347 over UDP; it is a good choice for transferring small amounts
of data across networks that follow the IP architecture.  Some CoAP
deployments, however, may have to integrate well with existing
enterprise infrastructure, where the use of UDP-based protocols may
not be well-received or may even be blocked by firewalls.
Middleboxes that are unaware of CoAP usage for IoT can make the use
of UDP brittle, resulting in lost or malformed packets.
Where NATs are still present, CoAP over TCP can also help with their
traversal.  NATs often calculate expiration timers based on the
transport layer protocol being used by application protocols.  Many
NATs are built around the assumption that a transport layer protocol,
such as TCP, gives them additional information about the session life
cycle and keep TCP-based NAT bindings around for a longer period.
UDP, on the other hand, does not provide such information to a NAT
and timeouts tend to be much shorter, as research confirms
HomeGateway.
Finally, CoAP may be integrated into a Web environment where the
front-end uses CoAP from IoT devices to a cloud infrastructure but
the CoAP messages are then transported in TCP between the back-end
services.  A TCP-to-UDP gateway can be used at the cloud boundary to
talk to the UDP-based IoT.
Conceptually, the CoAP over TCP/TLS specification replaces most of
CoAP's message layer by a new message adapter on top of TCP or TLS
that does provides a framing mechanism on top of the byte stream
provided by TCP/TLS, conveying the length information about each CoAP
message that on datagram transports is provided by the datagram layer
below (UDP, DTLS).
The Constrained Application Protocol (CoAP), although inspired by
HTTP, was designed to use UDP instead of TCP.  The message layer of
the CoAP over UDP protocol includes services for reliable delivery,
simple congestion control, and flow control.
Some environments would benefit from the availability of CoAP over a
reliable transport such as TCP or WebSockets, which already provides
such services.  This document outlines the changes required to use
CoAP over TCP, TLS, and WebSockets transports.
The RFC7252 was designed for Internet of Things (IoT) deployments,
assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used
unimpeded.  UDP is a good choice for transferring small amounts of
data across networks that follow the IP architecture.
Some CoAP deployments need to integrate well with existing enterprise
infrastructures, where UDP-based protocols may not be well-received
or may even be blocked by firewalls.  Middleboxes that are unaware of
CoAP usage for IoT can make the use of UDP brittle, resulting in lost
or malformed packets.
To address such environments, this document defines additional
bindings for CoAP, including TCP, TLS, and WebSockets.
Where NATs are present, CoAP over TCP can help with their traversal.
NATs often calculate expiration timers based on the transport layer
protocol being used by application protocols.  Many NATs maintain
TCP-based NAT bindings for longer periods based on the assumption
that a transport layer protocol, such as TCP, offers additional
information about the session life cycle.  UDP, on the other hand,
does not provide such information to a NAT and timeouts tend to be
much shorter, as confirmed by research HomeGateway.
Some environments may also benefit from the ability of TCP to
exchange larger payloads (such as firmware images) without
application layer segmentation and to utilize the more sophisticated
congestion control capabilities provided by many TCP implementations.
CoAP may be integrated into a Web environment where the front-end
uses CoAP over UDP from IoT devices to a cloud infrastructure and
then CoAP over TCP between the back-end services.  A TCP-to-UDP
gateway can be used at the cloud boundary to communicate with the
UDP-based IoT device.
Some corporate networks only allow Internet access via a HTTP proxy.
In this case, the best transport for CoAP would be the RFC6455.  The
WebSocket protocol provides two-way communication between a client
and a server after upgrading an RFC7230 connection and may be
available in an environment that blocks CoAP over UDP.  Another
scenario for CoAP over WebSockets is a CoAP application running
inside a web browser without access to connectivity other than HTTP
and WebSockets.
This document specifies how to access resources using CoAP requests
and responses over the WebSocket Protocol.  This allows connectivity-
limited applications to obtain end-to-end CoAP connectivity either by
communicating CoAP directly with a CoAP server accessible over a
WebSocket Connection or via a CoAP intermediary that proxies CoAP
requests and responses between different transports, such as between
WebSockets and UDP.
This document assumes that readers are familiar with the terms and
concepts that are used in RFC6455 and RFC7252.
EDITOR: These are "leftover" paragraphs from the original Overview
section.  Keeping until I perform a complete editorial pass of the
"roughed in" material.
Conceptually, the CoAP over TCP/TLS specification replaces most of
CoAP's message layer by a new message adapter on top of TCP or TLS
that provides a framing mechanism on top of the byte stream provided
by TCP/TLS, conveying the length information about each CoAP message
that on datagram transports is provided by the datagram layer below
(UDP, DTLS).
the 2-byte message length field causes another, larger upper bound
to the message length.
I-D.bormann-core-block-bert proposes to extend the block-wise
transfer protocol to allow for larger block sizes as are possible
over TCP and TLS.
The general assumption is therefore that the block protocol will
continue to be used over TCP, even if TCP-based applications
occasionally do exchange messages with payload sizes larger than
desirable in UDP.
EDITOR: This is extremely similar to the WebSocket section of the
same name.
CoAP RFC7252 defines the "coap" and "coaps" URI schemes for
identifying CoAP resources and providing a means of locating the
resource.  RFC 7252 defines these resources for use with CoAP over
UDP.
The present specification introduces two new URI schemes, namely
"coap+tcp" and "coaps+tcp".  The rules from Section 6 of RFC7252
apply to these two new URI schemes.
RFC7252, Section 8 (Multicast CoAP), does not apply to the URI
schemes defined in the present specification.
CoAP over WebSockets can be used in a number of configurations.  The
most basic configuration is a CoAP client seeking to retrieve or
update a CoAP resource located at a CoAP server that exposes a
WebSocket endpoint (arch-1).  The CoAP client takes the role of the
WebSocket client, establishes a WebSocket Connection and sends a CoAP
request, to which the CoAP server returns a CoAP response.  The
WebSocket Connection can be used for any number of requests.
The challenge in this configuration is to identify resource in the
namespace of the CoAP server: When the WebSocket Protocol is used by
a dedicated client directly (i.e., not from a web page through a web
browser), the client can connect to any WebSocket endpoint.  This
means it is necessary that the client is able to determine both the
WebSocket endpoint (identified by a "ws" or "wss" URI) and the path
and query of the CoAP resource within that endpoint from the same
URI.  When the WebSocket Protocol is used from a web page, the
choices are more limited RFC6454, but the challenge persists.
Another possible configuration is to set up a CoAP forward proxy at
the WebSocket endpoint.  Depending on what transports are available
to the proxy, it could forward the request to a CoAP server with a
CoAP UDP endpoint (arch-2), an SMS endpoint (a.k.a. mobile phone), or
even another WebSocket endpoint.  The client specifies the resource
to be updated or retrieved in the Proxy-URI Option.
A third possible configuration is a CoAP server running inside a web
browser (arch-3).  The web browser initially connects to a WebSocket
endpoint and is then reachable through the WebSocket server.  When no
connection exists, the CoAP server is not reachable; it therefore can
be considered a I-D.dijk-core-sleepy-reqs.  Because the WebSocket
server is the only way to reach the CoAP server, the CoAP proxy
should be a Reverse Proxy.
Further configurations are possible, including those where a
WebSocket Connection is established through an HTTP proxy.
CoAP over WebSockets is intentionally very similar to CoAP as defined
over UDP.  Therefore, instead of presenting CoAP over WebSockets as a
new protocol, this document specifies it as a series of deltas from
RFC7252.
Before CoAP requests and responses can be exchanged, a WebSocket
Connection needs to be established as defined in Section 4 of
RFC6455. handshake-example shows an example.
The WebSocket client MUST include the subprotocol name "coap" in the
list of protocols, which indicates support for the protocol defined
in this document.  Any later, incompatible versions of CoAP or CoAP
over WebSockets will use a different subprotocol name.
The WebSocket client includes the hostname of the WebSocket server in
the Host header field of its handshake as per RFC6455.  The Host
header field also indicates the default value of the Uri-Host Option
in requests from the WebSocket client to the WebSocket server.
Once a WebSocket Connection has been established, CoAP requests and
responses can be exchanged as WebSocket messages.  Since CoAP uses a
binary message format, the messages are transmitted in binary data
frames as specified in Sections 5 and 6 of RFC6455.
Since the underlying TCP connection provides retransmissions and
deduplication, there is no need for the reliability mechanisms
provided by CoAP over UDP.  This means the "T" and "Message ID"
fields in the CoAP message header can be elided.
Furthermore, since the CoAP version is already negotiated during
the opening handshake, the "Ver" field can be elided as well.
The resulting message format is shown in ws-message-format.  The four
most-significant bits of the first byte are reserved (R) and MUST be
set to zero.  The remaining fields and structure are the same as
defined in RFC7252.
Requests and response messages can be fragmented as specified in
Section 5.4 of RFC6455, though typically they are sent unfragmented
as they tend to be small and fully buffered before transmission.  The
WebSocket protocol does not provide means for multiplexing; if it is
not desirable for a large message to monopolize the connection,
requests and responses can be transferred in a blockwise fashion as
defined in I-D.ietf-core-block.
Messages MUST NOT be Empty (Code 0.00), i.e., messages always carry
either a request or a response.
CoAP requests and responses are exchanged asynchronously over the
WebSocket Connection, i.e., a CoAP client can send multiple requests
without waiting for a response and the CoAP server can return
responses in any order.  Responses MUST be returned over the same
connection as the originating request.  Concurrent requests are
differentiated by their Token, which is scoped locally to the
connection.
The connection is bi-directional, so requests can be sent both by the
entity that established the connection and the remote host.
Retransmission and deduplication of messages is provided by the
WebSocket Protocol.  CoAP over WebSockets therefore does not make a
distinction between Confirmable or Non-Confirmable messages, and does
not provide Acknowledgement or Reset messages.
Since the WebSocket Protocol provides ordered delivery of messages,
the mechanism for reordering detection when RFC7641 is not needed.
The value of the Observe Option in notifications therefore MAY be
empty on transmission and MUST be ignored on reception.
When a client does not receive any response for some time after
sending a CoAP request (or, similarly, when a client observes a
resource and it does not receive any notification for some time), the
connection between the WebSocket client and the WebSocket server may
be lost or temporarily disrupted without the client being aware of
it.
To check the health of the WebSocket Connection (and thereby of all
active requests, if any), the client can send a Ping frame or an
unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There
is no way to retransmit a request without creating a new one.  Re-
registering interest in a resource is permitted, but entirely
unnecessary.
The WebSocket Connection is closed as specified in Section 7 of
RFC6455.
All requests for which the CoAP client has not received a response
yet are cancelled when the connection is closed.  If the client
observes one or more resources over the WebSocket Connection, then
the CoAP server (or intermediary in the role of the CoAP server) MUST
remove all entries associated with the client from the lists of
observers when the connection is closed.
CoAP over UDP RFC7252 defines the "coap" and "coaps" URI schemes for
identifying CoAP resources and providing a means of locating the
resource.
CoAP over TCP uses "coap_tcp" URI scheme.  CoAP over TLS uses the
"coaps+tcp" scheme.  The rules from Section 6 of RFC7252 apply to
both of these URI schemes.
RFC7252, Section 8 (Multicast CoAP) is not applicable to these
schemes.
This document defines how to convey CoAP over TCP and TLS.  CoAP
RFC7252 makes use of DTLS 1.2 and this specification consequently
uses TLS 1.2 RFC5246.  CoAP MUST NOT be used with older versions of
TLS.  Guidelines for use of cipher suites and TLS extensions can be
found in I-D.ietf-dice-profile.
For the first configuration discussed in overview, this document
defines two new URIs schemes that can be used for identifying CoAP
resources and providing a means of locating these resources:
"coap+ws" and "coap+wss".
Similar to the "coap" and "coaps" schemes, the "coap+ws" and
"coap+wss" schemes organize resources hierarchically under a CoAP
origin server.  The key difference is that the server is potentially
reachable on a WebSocket endpoint instead of a UDP endpoint.
The WebSocket endpoint is identified by a "ws" or "wss" URI that is
composed of the authority part of the "coap+ws" or "coap+wss" URI,
respectively, and the well-known path "/.well-known/coap" RFC5785.
The path and query parts of a "coap+ws" or "coap+wss" URI identify a
resource within the specified endpoint which can be operated on by
the methods defined by the CoAP protocol.
The syntax of the "coap+ws" and "coap+wss" URI schemes is specified
below in Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions
of "host", "port", "path-abempty" and "query" are the same as in
RFC3986.
The port component is OPTIONAL; the default for "coap+ws" is port 80,
while the default for "coap+wss" is port 443.
Fragment identifiers are not part of the request URI and thus MUST
NOT be transmitted in a WebSocket handshake or in the URI options of
a CoAP request.
The <scheme> component MUST be "coap+ws" or "coap+wss" when
converted to ASCII lowercase.
A Uri-Host Option MUST only be included in a request when the
<host> component does not equal the uri-host component in the Host
header field in the WebSocket handshake.
A Uri-Port Option MUST only be included in a request if |port|
does not equal the port component in the Host header field in the
WebSocket handshake.
The steps to construct a URI from a request's options are changed
accordingly.
Implementations of CoAP MUST use TLS version 1.2 or higher for CoAP
over TLS.  The general TLS usage guidance in RFC7525 SHOULD be
followed.
Guidelines for use of cipher suites and TLS extensions can be found
in I-D.ietf-dice-profile.
CoAP over WebSockets and CoAP over TLS-secured WebSockets do not
introduce additional security issues beyond CoAP and DTLS-secured
CoAP respectively RFC7252.  The security considerations of RFC6455
apply.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+ws".  The registration request complies
with RFC4395.
The "coap+ws" URI scheme provides a way to identify resources that
are potentially accessible over the Constrained Application
Protocol (CoAP) using the WebSocket Protocol.
The scheme is used by CoAP endpoints to access CoAP resources
using the WebSocket protocol.
This document requests the registration of the Uniform Resource
Identifier (URI) scheme "coap+wss".  The registration request
complies with RFC4395.
The "coap+ws" URI scheme provides a way to identify resources that
are potentially accessible over the Constrained Application
Protocol (CoAP) using the WebSocket Protocol secured with
Transport Layer Security (TLS).
The scheme is used by CoAP endpoints to access CoAP resources
using the WebSocket protocol secured with TLS.