draft-ietf-core-coap-tcp-tls-07.txt   draft-ietf-core-coap-tcp-tls-08.txt 
CORE C. Bormann CORE C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Updates: 7641 (if approved) S. Lemay Updates: 6455, 7641, 7959 (if approved) S. Lemay
Intended status: Standards Track Zebra Technologies Intended status: Standards Track Zebra Technologies
Expires: September 7, 2017 H. Tschofenig Expires: October 23, 2017 H. Tschofenig
ARM Ltd. ARM Ltd.
K. Hartke K. Hartke
Universitaet Bremen TZI Universitaet Bremen TZI
B. Silverajan B. Silverajan
Tampere University of Technology Tampere University of Technology
B. Raymor, Ed. B. Raymor, Ed.
Microsoft Microsoft
March 06, 2017 April 21, 2017
CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
draft-ietf-core-coap-tcp-tls-07 draft-ietf-core-coap-tcp-tls-08
Abstract Abstract
The Constrained Application Protocol (CoAP), although inspired by The Constrained Application Protocol (CoAP), although inspired by
HTTP, was designed to use UDP instead of TCP. The message layer of HTTP, was designed to use UDP instead of TCP. The message layer of
the CoAP over UDP protocol includes support for reliable delivery, the CoAP over UDP protocol includes support for reliable delivery,
simple congestion control, and flow control. simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS. This document outlines the reliable transports such as TCP or TLS. This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets changes required to use CoAP over TCP, TLS, and WebSockets
transports. It also formally updates [RFC7641] for use with these transports. It also formally updates RFC 7641 for use with these
transports. transports, RFC 7959 to enable the use of larger messages over a
reliable transport, and RFC 6455 to extend the well-known URI
mechanism (RFC 5785) to the ws and wss URI schemes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 23, 2017.
This Internet-Draft will expire on September 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 28
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 6 3. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Messaging Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7 3.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7
3.3. Message Transmission . . . . . . . . . . . . . . . . . . 10 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 11
3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 11 3.4. Connection Health . . . . . . . . . . . . . . . . . . . . 12
4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 11 4. CoAP over WebSockets . . . . . . . . . . . . . . . . . . . . 12
4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 13 4.1. Opening Handshake . . . . . . . . . . . . . . . . . . . . 14
4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 14
4.3. Message Transmission . . . . . . . . . . . . . . . . . . 15 4.3. Message Transmission . . . . . . . . . . . . . . . . . . 15
4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 15 4.4. Connection Health . . . . . . . . . . . . . . . . . . . . 16
5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16 5.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . . 16
5.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16 5.2. Signaling Option Numbers . . . . . . . . . . . . . . . . 16
5.3. Capabilities and Settings Messages (CSM) . . . . . . . . 16 5.3. Capabilities and Settings Messages (CSM) . . . . . . . . 17
5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18 5.4. Ping and Pong Messages . . . . . . . . . . . . . . . . . 18
5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19 5.5. Release Messages . . . . . . . . . . . . . . . . . . . . 19
5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20 5.6. Abort Messages . . . . . . . . . . . . . . . . . . . . . 20
5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 21 5.7. Signaling examples . . . . . . . . . . . . . . . . . . . 21
6. Block-wise Transfer and Reliable Transports . . . . . . . . . 22 6. Block-wise Transfer and Reliable Transports . . . . . . . . . 22
6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23 6.1. Example: GET with BERT Blocks . . . . . . . . . . . . . . 23
6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 24 6.2. Example: PUT with BERT Blocks . . . . . . . . . . . . . . 24
7. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 24 7. CoAP over Reliable Transport URIs . . . . . . . . . . . . . . 24
7.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 25 7.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 25
7.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 25 7.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 26
7.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 26 7.3. coap+ws URI scheme . . . . . . . . . . . . . . . . . . . 27
7.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 27 7.4. coaps+ws URI scheme . . . . . . . . . . . . . . . . . . . 27
7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 28 7.5. Uri-Host and Uri-Port Options . . . . . . . . . . . . . . 28
7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 28 7.6. Decomposing URIs into Options . . . . . . . . . . . . . . 29
7.7. Composing URIs from Options . . . . . . . . . . . . . . . 29 7.7. Composing URIs from Options . . . . . . . . . . . . . . . 29
8. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 30 8.1. TLS binding for CoAP over TCP . . . . . . . . . . . . . . 30
8.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 30 8.2. TLS usage for CoAP over WebSockets . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 31 9.1. Signaling Messages . . . . . . . . . . . . . . . . . . . 31
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 31 10.1. Signaling Codes . . . . . . . . . . . . . . . . . . . . 32
10.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 32 10.2. CoAP Signaling Option Numbers Registry . . . . . . . . . 32
10.3. Service Name and Port Number Registration . . . . . . . 33 10.3. Service Name and Port Number Registration . . . . . . . 33
10.4. Secure Service Name and Port Number Registration . . . . 34 10.4. Secure Service Name and Port Number Registration . . . . 34
10.5. URI Scheme Registration . . . . . . . . . . . . . . . . 34 10.5. URI Scheme Registration . . . . . . . . . . . . . . . . 34
10.6. Well-Known URI Suffix Registration . . . . . . . . . . . 37 10.6. Well-Known URI Suffix Registration . . . . . . . . . . . 37
10.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 37 10.7. ALPN Protocol Identifier . . . . . . . . . . . . . . . . 37
10.8. WebSocket Subprotocol Registration . . . . . . . . . . . 37 10.8. WebSocket Subprotocol Registration . . . . . . . . . . . 37
10.9. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Normative References . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . 38
11.2. Informative References . . . . . . . . . . . . . . . . . 39 11.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Updates to RFC 7641 Observing Resources in the Appendix A. Updates to RFC 7641 Observing Resources in the
Constrained Application Protocol (CoAP) . . . . . . 40 Constrained Application Protocol (CoAP) . . . . . . 41
A.1. Notifications and Reordering . . . . . . . . . . . . . . 40 A.1. Notifications and Reordering . . . . . . . . . . . . . . 41
A.2. Transmission and Acknowledgements . . . . . . . . . . . . 41 A.2. Transmission and Acknowledgements . . . . . . . . . . . . 41
A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 41 A.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 41
A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 41 A.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 42 Appendix B. CoAP over WebSocket Examples . . . . . . . . . . . . 42
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 45 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 46
C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 45 C.1. Since draft-ietf-core-coap-tcp-tls-02 . . . . . . . . . . 46
C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 45 C.2. Since draft-ietf-core-coap-tcp-tls-03 . . . . . . . . . . 46
C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 45 C.3. Since draft-ietf-core-coap-tcp-tls-04 . . . . . . . . . . 46
C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 45 C.4. Since draft-ietf-core-coap-tcp-tls-05 . . . . . . . . . . 46
C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 46 C.5. Since draft-ietf-core-coap-tcp-tls-06 . . . . . . . . . . 47
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 46 C.6. Since draft-ietf-core-coap-tcp-tls-07 . . . . . . . . . . 47
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] was designed The Constrained Application Protocol (CoAP) [RFC7252] was designed
for Internet of Things (IoT) deployments, assuming that UDP [RFC0768] for Internet of Things (IoT) deployments, assuming that UDP [RFC0768]
or DTLS [RFC6347] over UDP can be used unimpeded. UDP is a good or Datagram Transport Layer Security (DTLS) [RFC6347] over UDP can be
choice for transferring small amounts of data across networks that used unimpeded. UDP is a good choice for transferring small amounts
follow the IP architecture. of data across networks that follow the IP architecture.
Some CoAP deployments need to integrate well with existing enterprise Some CoAP deployments need to integrate well with existing enterprise
infrastructures, where UDP-based protocols may not be well-received infrastructures, where UDP-based protocols may not be well-received
or may even be blocked by firewalls. Middleboxes that are unaware of 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 CoAP usage for IoT can make the use of UDP brittle, resulting in lost
or malformed packets. or malformed packets.
Emerging standards such as Lightweight Machine to Machine [LWM2M] Emerging standards such as Lightweight Machine to Machine [LWM2M]
currently use CoAP over UDP as a transport and require support for currently use CoAP over UDP as a transport and require support for
CoAP over TCP to address the issues above and to protect investments CoAP over TCP to address the issues above and to protect investments
skipping to change at page 5, line 9 skipping to change at page 5, line 12
CoAP may be integrated into a Web environment where the front-end CoAP may be integrated into a Web environment where the front-end
uses CoAP over UDP from IoT devices to a cloud infrastructure and 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 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 gateway can be used at the cloud boundary to communicate with the
UDP-based IoT device. UDP-based IoT device.
To allow IoT devices to better communicate in these demanding To allow IoT devices to better communicate in these demanding
environments, CoAP needs to support different transport protocols, environments, CoAP needs to support different transport protocols,
namely TCP [RFC0793], in some situations secured by TLS [RFC5246]. namely TCP [RFC0793], in some situations secured by TLS [RFC5246].
In addition, some corporate networks only allow Internet access via a CoAP applications running inside a web browser without access to
HTTP proxy. In this case, the best transport for CoAP might be the connectivity other than HTTP and the WebSocket protocol [RFC6455] may
WebSocket protocol [RFC6455]. The WebSocket protocol provides two- cross-proxy their CoAP requests via HTTP to a HTTP-to-CoAP cross-
way communication between a WebSocket client and a WebSocket server proxy or transport them via the the WebSocket protocol, which
after upgrading an HTTP/1.1 [RFC7230] connection and may be available provides two-way communication between a WebSocket client and a
in an environment that blocks CoAP over UDP. Another scenario for WebSocket server after upgrading an HTTP/1.1 [RFC7230] connection.
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 This document specifies how to access resources using CoAP requests
and responses over the TCP, TLS and WebSocket protocols. This allows and responses over the TCP, TLS and WebSocket protocols. This allows
connectivity-limited applications to obtain end-to-end CoAP connectivity-limited applications to obtain end-to-end CoAP
connectivity either by communicating CoAP directly with a CoAP server connectivity either by communicating CoAP directly with a CoAP server
accessible over a TCP, TLS or WebSocket connection or via a CoAP accessible over a TCP, TLS or WebSocket connection or via a CoAP
intermediary that proxies CoAP requests and responses between intermediary that proxies CoAP requests and responses between
different transports, such as between WebSockets and UDP. different transports, such as between WebSockets and UDP.
Appendix A updates the "Observing Resources in the Constrained Appendix A updates the "Observing Resources in the Constrained
skipping to change at page 5, line 50 skipping to change at page 5, line 50
[RFC2119]. [RFC2119].
This document assumes that readers are familiar with the terms and This document assumes that readers are familiar with the terms and
concepts that are used in [RFC6455], [RFC7252], [RFC7641], and concepts that are used in [RFC6455], [RFC7252], [RFC7641], and
[RFC7959]. [RFC7959].
The term "reliable transport" is used only to refer to transport The term "reliable transport" is used only to refer to transport
protocols, such as TCP, which provide reliable and ordered delivery protocols, such as TCP, which provide reliable and ordered delivery
of a byte-stream. of a byte-stream.
Block-wise Extension for Reliable Transport (BERT):
BERT extends [RFC7959] to enable the use of larger messages over a
reliable transport.
BERT Option: BERT Option:
A Block1 or Block2 option that includes an SZX value of 7. A Block1 or Block2 option that includes an SZX value of 7.
BERT Block: BERT Block:
The payload of a CoAP message that is affected by a BERT Option in The payload of a CoAP message that is affected by a BERT Option in
descriptive usage (see Section 2.1 of [RFC7959]). descriptive usage (see Section 2.1 of [RFC7959]).
Connection Initiator: Connection Initiator:
The peer that opens a reliable byte stream connection, i.e., the The peer that opens a reliable byte stream connection, i.e., the
TCP active opener, TLS client, or WebSocket client. TCP active opener, TLS client, or WebSocket client.
skipping to change at page 11, line 22 skipping to change at page 11, line 41
CoAP requests and responses are exchanged asynchronously over the CoAP requests and responses are exchanged asynchronously over the
TCP/TLS connection. A CoAP client can send multiple requests without TCP/TLS connection. A CoAP client can send multiple requests without
waiting for a response and the CoAP server can return responses in waiting for a response and the CoAP server can return responses in
any order. Responses MUST be returned over the same connection as any order. Responses MUST be returned over the same connection as
the originating request. Concurrent requests are differentiated by the originating request. Concurrent requests are differentiated by
their Token, which is scoped locally to the connection. their Token, which is scoped locally to the connection.
The connection is bi-directional, so requests can be sent both by the The connection is bi-directional, so requests can be sent both by the
entity that established the connection (Connection Initiator) and the entity that established the connection (Connection Initiator) and the
remote host (Connection Acceptor). If one side does not implement a remote host (Connection Acceptor). If one side does not implement a
CoAP server, an appropriate error response such as 4.04 (Not Found) CoAP server, an error response MUST be returned for all CoAP requests
or 5.01 (Not Implemented) MUST be returned for all CoAP requests from from the other side. The simplest approach is to always return 5.01
the other side. (Not Implemented). A more elaborate mock server could also return
4.xx responses such as 4.04 (Not Found) or 4.02 (Bad Option) where
appropriate.
Retransmission and deduplication of messages is provided by the TCP Retransmission and deduplication of messages is provided by the TCP
protocol. protocol.
3.4. Connection Health 3.4. Connection Health
Empty messages (Code 0.00) can always be sent and MUST be ignored by Empty messages (Code 0.00) can always be sent and MUST be ignored by
the recipient. This provides a basic keep-alive function that can the recipient. This provides a basic keep-alive function that can
refresh NAT bindings. refresh NAT bindings.
If a CoAP client does not receive any response for some time after If a CoAP client does not receive any response for some time after
sending a CoAP request (or, similarly, when a client observes a sending a CoAP request (or, similarly, when a client observes a
resource and it does not receive any notification for some time), it resource and it does not receive any notification for some time), it
can send a CoAP Ping Signaling message (see Section 5.4) to test the can send a CoAP Ping Signaling message (see Section 5.4) to test the
connection and verify that the CoAP server is responsive. connection and verify that the CoAP server is responsive.
When the underlying TCP connection is closed or reset, the signaling
state and any observation state (see Appendix A.4) associated with
the reliable connection are removed. In flight messages may or may
not be lost.
4. CoAP over WebSockets 4. CoAP over WebSockets
CoAP over WebSockets is intentionally similar to CoAP over TCP; CoAP over WebSockets is intentionally similar to CoAP over TCP;
therefore, this section only specifies the differences between the therefore, this section only specifies the differences between the
transports. transports.
CoAP over WebSockets can be used in a number of configurations. The CoAP over WebSockets can be used in a number of configurations. The
most basic configuration is a CoAP client retrieving or updating a most basic configuration is a CoAP client retrieving or updating a
CoAP resource located on a CoAP server that exposes a WebSocket CoAP resource located on a CoAP server that exposes a WebSocket
endpoint (see Figure 9). The CoAP client acts as the WebSocket endpoint (see Figure 9). The CoAP client acts as the WebSocket
skipping to change at page 25, line 14 skipping to change at page 25, line 18
o the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS o the "coaps+ws" URI scheme for CoAP over WebSockets secured by TLS
Resources made available via these schemes have no shared identity Resources made available via these schemes have no shared identity
even if their resource identifiers indicate the same authority (the even if their resource identifiers indicate the same authority (the
same host listening to the same TCP port). They are hosted in same host listening to the same TCP port). They are hosted in
distinct namespaces because each URI scheme implies a distinct origin distinct namespaces because each URI scheme implies a distinct origin
server. server.
The syntax for the URI schemes in this section are specified using The syntax for the URI schemes in this section are specified using
Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of Augmented Backus-Naur Form (ABNF) [RFC5234]. The definitions of
"host", "port", "path-abempty", and "query" are adopted from "host", "port", "path-abempty", "query", and "fragment" are adopted
[RFC3986]. from [RFC3986].
Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these Section 8 (Multicast CoAP) in [RFC7252] is not applicable to these
schemes. schemes.
As with the "coap" and "coaps" schemes defined in [RFC7252], all URI
schemes defined in this section also support the path prefix "/.well-
known/" defined by [RFC5785] for "well-known locations" in the
namespace of a host. This enables discovery as per Section 7 of
[RFC7252].
7.1. coap+tcp URI scheme 7.1. coap+tcp URI scheme
The "coap+tcp" URI scheme identifies CoAP resources that are intended The "coap+tcp" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over TCP. to be accessible using CoAP over TCP.
coap+tcp-URI = coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ]
"coap+tcp:" "//" host [ ":" port ] path-abempty [ "?" query ] path-abempty [ "?" query ] [ "#" fragment ]
The syntax defined in Section 6.1 of [RFC7252] applies to this URI The syntax defined in Section 6.1 of [RFC7252] applies to this URI
scheme with the following changes: scheme with the following changes:
o The port subcomponent indicates the TCP port at which the CoAP o The port subcomponent indicates the TCP port at which the CoAP
server is located. (If it is empty or not given, then the default server is located. (If it is empty or not given, then the default
port 5683 is assumed, as with UDP.) port 5683 is assumed, as with UDP.)
Encoding considerations: The scheme encoding conforms to the Encoding considerations: The scheme encoding conforms to the
encoding rules established for URIs in [RFC3986]. encoding rules established for URIs in [RFC3986].
Interoperability considerations: None. Interoperability considerations: None.
Security considerations: See Section 11.1 of [RFC7252]. Security considerations: See Section 11.1 of [RFC7252].
7.2. coaps+tcp URI scheme 7.2. coaps+tcp URI scheme
The "coaps+tcp" URI scheme identifies CoAP resources that are The "coaps+tcp" URI scheme identifies CoAP resources that are
intended to be accessible using CoAP over TCP secured with TLS. intended to be accessible using CoAP over TCP secured with TLS.
coaps+tcp-URI = coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ]
"coaps+tcp:" "//" host [ ":" port ] path-abempty [ "?" query ] path-abempty [ "?" query ] [ "#" fragment ]
The syntax defined in Section 6.2 of [RFC7252] applies to this URI The syntax defined in Section 6.2 of [RFC7252] applies to this URI
scheme, with the following changes: scheme, with the following changes:
o The port subcomponent indicates the TCP port at which the TLS o The port subcomponent indicates the TCP port at which the TLS
server for the CoAP server is located. If it is empty or not server for the CoAP server is located. If it is empty or not
given, then the default port 443 is assumed (this is different given, then the default port 443 is assumed (this is different
from the default port for "coaps", i.e., CoAP over DTLS over UDP). from the default port for "coaps", i.e., CoAP over DTLS over UDP).
o If a TLS server does not support the Application-Layer Protocol o If a TLS server does not support the Application-Layer Protocol
skipping to change at page 26, line 51 skipping to change at page 27, line 14
Interoperability considerations: None. Interoperability considerations: None.
Security considerations: See Section 11.1 of [RFC7252]. Security considerations: See Section 11.1 of [RFC7252].
7.3. coap+ws URI scheme 7.3. coap+ws URI scheme
The "coap+ws" URI scheme identifies CoAP resources that are intended The "coap+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets. to be accessible using CoAP over WebSockets.
coap-ws-URI = coap-ws-URI = "coap+ws:" "//" host [ ":" port ]
"coap+ws:" "//" host [ ":" port ] path-abempty [ "?" query ] path-abempty [ "?" query ] [ "#" fragment ]
The port subcomponent is OPTIONAL. The default is port 80. The port subcomponent is OPTIONAL. The default is port 80.
The WebSocket endpoint is identified by a "ws" URI that is composed The WebSocket endpoint is identified by a "ws" URI that is composed
of the authority part of the "coap+ws" URI and the well-known path of the authority part of the "coap+ws" URI and the well-known path
"/.well-known/coap" [RFC5785]. The path and query parts of a "/.well-known/coap" [RFC5785]. The present specification formally
"coap+ws" URI identify a resource within the specified endpoint which updates [RFC6455], extending the well-known URI mechanism defined in
can be operated on by the methods defined by CoAP: [RFC5785] to also cover the "ws" URI scheme defined in that document.
The path and query parts of a "coap+ws" URI identify a resource
within the specified endpoint which can be operated on by the methods
defined by CoAP:
coap+ws://example.org/sensors/temperature?u=Cel coap+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/ \______ ______/\___________ ___________/
\/ \/ \/ \/
Uri-Path: "sensors" Uri-Path: "sensors"
ws://example.org/.well-known/coap Uri-Path: "temperature" ws://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel" Uri-Query: "u=Cel"
Figure 18: The "coap+ws" URI Scheme Figure 18: The "coap+ws" URI Scheme
skipping to change at page 27, line 34 skipping to change at page 27, line 49
Interoperability considerations: None. Interoperability considerations: None.
Security considerations: See Section 11.1 of [RFC7252]. Security considerations: See Section 11.1 of [RFC7252].
7.4. coaps+ws URI scheme 7.4. coaps+ws URI scheme
The "coaps+ws" URI scheme identifies CoAP resources that are intended The "coaps+ws" URI scheme identifies CoAP resources that are intended
to be accessible using CoAP over WebSockets secured by TLS. to be accessible using CoAP over WebSockets secured by TLS.
coaps-ws-URI = coaps-ws-URI = "coaps+ws:" "//" host [ ":" port ]
"coaps+ws:" "//" host [ ":" port ] path-abempty [ "?" query ] path-abempty [ "?" query ] [ "#" fragment ]
The port subcomponent is OPTIONAL. The default is port 443. The port subcomponent is OPTIONAL. The default is port 443.
The WebSocket endpoint is identified by a "wss" URI that is composed The WebSocket endpoint is identified by a "wss" URI that is composed
of the authority part of the "coaps+ws" URI and the well-known path of the authority part of the "coaps+ws" URI and the well-known path
"/.well-known/coap" [RFC5785]. The path and query parts of a "/.well-known/coap" [RFC5785]. The present specification formally
"coaps+ws" URI identify a resource within the specified endpoint updates [RFC6455], extending the well-known URI mechanism defined in
which can be operated on by the methods defined by CoAP. [RFC5785] to also cover the "wss" URI scheme defined in that
document. The path and query parts of a "coaps+ws" URI identify a
resource within the specified endpoint which can be operated on by
the methods defined by CoAP.
coaps+ws://example.org/sensors/temperature?u=Cel coaps+ws://example.org/sensors/temperature?u=Cel
\______ ______/\___________ ___________/ \______ ______/\___________ ___________/
\/ \/ \/ \/
Uri-Path: "sensors" Uri-Path: "sensors"
wss://example.org/.well-known/coap Uri-Path: "temperature" wss://example.org/.well-known/coap Uri-Path: "temperature"
Uri-Query: "u=Cel" Uri-Query: "u=Cel"
Figure 19: The "coaps+ws" URI Scheme Figure 19: The "coaps+ws" URI Scheme
skipping to change at page 30, line 35 skipping to change at page 31, line 8
PreSharedKey: TLS is enabled. The guidance in Section 4.2 of PreSharedKey: TLS is enabled. The guidance in Section 4.2 of
[RFC7925] applies. [RFC7925] applies.
RawPublicKey: TLS is enabled. The guidance in Section 4.3 of RawPublicKey: TLS is enabled. The guidance in Section 4.3 of
[RFC7925] applies. [RFC7925] applies.
Certificate: TLS is enabled. The guidance in Section 4.4 of Certificate: TLS is enabled. The guidance in Section 4.4 of
[RFC7925] applies. [RFC7925] applies.
The "NoSec" mode is mandatory-to-implement. The system simply sends The "NoSec" mode is optional-to-implement. The system simply sends
the packets over normal TCP which is indicated by the "coap+tcp" the packets over normal TCP which is indicated by the "coap+tcp"
scheme and the TCP CoAP default port. The system is secured only by scheme and the TCP CoAP default port. The system is secured only by
keeping attackers from being able to send or receive packets from the keeping attackers from being able to send or receive packets from the
network with the CoAP nodes. network with the CoAP nodes.
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to- "PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-
implement for the TLS binding depending on the credential type used implement for the TLS binding depending on the credential type used
with the device. These security modes are achieved using TLS and are with the device. These security modes are achieved using TLS and are
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
port. port.
skipping to change at page 38, line 7 skipping to change at page 38, line 7
Subprotocol Identifier. Subprotocol Identifier.
coap coap
Subprotocol Common Name. Subprotocol Common Name.
Constrained Application Protocol (CoAP) Constrained Application Protocol (CoAP)
Subprotocol Definition. Subprotocol Definition.
[RFCthis] [RFCthis]
10.9. CoAP Option Numbers Registry
IANA is requested to add [RFCthis] to the references for the
following entries registered by [RFC7959] in the "CoAP Option
Numbers" sub-registry defined by [RFC7252]:
+--------+--------+---------------------+
| Number | Name | Reference |
+--------+--------+---------------------+
| 23 | Block2 | RFC 7959, [RFCthis] |
| | | |
| 27 | Block1 | RFC 7959, [RFCthis] |
+--------+--------+---------------------+
Table 3: CoAP Option Numbers
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>. <http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 39, line 26 skipping to change at page 39, line 45
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>. <http://www.rfc-editor.org/info/rfc7641>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, DOI 10.17487/RFC7925, July 2016,
<http://www.rfc-editor.org/info/rfc7925>. <http://www.rfc-editor.org/info/rfc7925>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
11.2. Informative References 11.2. Informative References
[HomeGateway] [HomeGateway]
Eggert, L., "An experimental study of home gateway Eggert, L., "An experimental study of home gateway
characteristics", Proceedings of the 10th annual characteristics", Proceedings of the 10th annual
conference on Internet measurement , 2010. conference on Internet measurement , 2010.
[I-D.ietf-core-cocoa] [I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-ietf- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-00 (work in progress), October 2016. core-cocoa-01 (work in progress), March 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core- "Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016. object-security-02 (work in progress), March 2017.
[LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine [LWM2M] Open Mobile Alliance, "Lightweight Machine to Machine
Technical Specification Version 1.0", February 2017, Technical Specification Version 1.0", February 2017,
<http://www.openmobilealliance.org/release/LightweightM2M/ <http://www.openmobilealliance.org/release/LightweightM2M/
V1_0-20170208-A/ V1_0-20170208-A/
OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>. OMA-TS-LightweightM2M-V1_0-20170208-A.pdf>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>. <http://www.rfc-editor.org/info/rfc768>.
skipping to change at page 40, line 26 skipping to change at page 41, line 5
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
[SecurityChallenges] [SecurityChallenges]
Polk, T. and S. Turner, "Security Challenges for the Polk, T. and S. Turner, "Security Challenges for the
Internet of Things", Interconnecting Smart Objects with Internet of Things", Interconnecting Smart Objects with
the Internet / IAB Workshop , February 2011, the Internet / IAB Workshop , February 2011,
<http://www.iab.org/wp-content/IAB-uploads/2011/03/ <http://www.iab.org/wp-content/IAB-uploads/2011/03/
Turner.pdf>. Turner.pdf>.
Appendix A. Updates to RFC 7641 Observing Resources in the Constrained Appendix A. Updates to RFC 7641 Observing Resources in the Constrained
Application Protocol (CoAP) Application Protocol (CoAP)
skipping to change at page 46, line 10 skipping to change at page 47, line 10
Updated Pong response requirements Updated Pong response requirements
Added Connection Initiator and Connection Acceptor terminology where Added Connection Initiator and Connection Acceptor terminology where
appropriate appropriate
Updated LWM2M 1.0 informative reference Updated LWM2M 1.0 informative reference
C.5. Since draft-ietf-core-coap-tcp-tls-06 C.5. Since draft-ietf-core-coap-tcp-tls-06
Addressed feedback from second Working Group Last Call Addressed feedback from second Working Group Last Call
C.6. Since draft-ietf-core-coap-tcp-tls-07
Addressed feedback from IETF Last Call
Addressed feedback from ARTART review
Addressed feedback from GENART review
Addressed feedback from TSVART review
Added fragment identifiers to URI schemes
Added "Updates RFC7959" for BERT
Added "Updates RFC6455" to extend well-known URI mechanism to ws and
wss
Clarified well-known URI mechanism use for all URI schemes
Changed NoSec to optional-to-implement
Acknowledgements Acknowledgements
We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier
Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster, Delaby, Esko Dijk, Christian Groves, Nadir Javed, Michael Koster,
Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran Matthias Kovatsch, Achim Kraus, David Navarro, Szymon Sasin, Goran
Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu Selander, Zach Shelby, Andrew Summers, Julien Vermillard, and Gengyu
Wei for their feedback. Wei for their feedback.
Contributors Contributors
Matthias Kovatsch Matthias Kovatsch
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich D-81739 Munich D-81739
Phone: +49-173-5288856 Phone: +49-173-5288856
EMail: matthias.kovatsch@siemens.com EMail: matthias.kovatsch@siemens.com
Teemu Savolainen Teemu Savolainen
Nokia Technologies Nokia Technologies
 End of changes. 40 change blocks. 
75 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/