]> Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

christian@amsuess.com

Internet-Draft In CoAP as defined by RFC 7252, there is generally one response for each request. Various CoAP extensions have individually relaxed that practice. The present memo presents a generalized model beyond 1:1 responses, describes different forms in which it can be used, and introduces new CoAP Options that make use of that model. Beyond that, this document provides implementation guidance to simplify prior extensions, and outlines future possibilities of using it. This revision -01 has been created as discussion input for IETF 126. It makes a first attempt to sort the proposals into short-term actionable ones and more long-term considerations for more kinds of responses that could help additional use cases through future work. About This Document Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments (CoRE) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In CoAP as defined by , in general, a single response is sent to the client that posed a request. That practice has been relaxed:

• in itself (and later ) for multicast requests,
• in for multiple responses following an observation request,
• in for not sending a response at all,
• in for requesting a series of response blocks,
• as well as in drafts such as and .

The present memo provides a general model for such responses, and describes two concrete forms using that model, with embedded or configured requests. It sets up a CoAP option for a client to enable additional responses, and an option that can be used to embed a request in a response. Further work is needed on responses for configured requests, which are discussed in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in () () when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". Terms used in this specification:

Non-traditional response:

A response that is not the single response generated for a request received on the same transport.

Non-matching response:

A response that has properties (typically options) that make it incompatible with the original request, and thus in particular unsuitable as a cached response to that request (but possibly suitable to populate the cache for a similar request). Options that make a response non-matching need to be proxy unsafe. For example, a Block2 response with a different value of block number × block size than indicated in the request is non-matching.

Configured request:

A request that reaches the server in another way than by transmitting a usual CoAP request on the same communication channel a response is expected on.

Embedded request:

A request that is provided by the server to the recipient of its response by embedding it into the response.

Sending Non-traditional Responses Non-traditional responses are sets of responses produced for a single request, or responses sent without a transmitted request. Where tokens are involved, all non-traditional responses use the request's token; in any case, they are bound to the original request (e.g. by using the same request_kid/request_piv pair in OSCORE ). Where message IDs are involved, one of the non-traditional responses (the first sent, not necessarily the first received as generally the network might reorder messages) can be sent as a piggybacked response in an ACK (thus sharing the request's message ID); the others are CON or NON responses. Some established responses (observations defined in , and responses to multicast requests in ) match this definition and already follow the guidance set out here for non-traditional responses; gives details for them. A second response differing from the first that can be sent by a non-deduplicating server responding to a retransmission of a request is not non-traditional because there is a second request — that is probably the last corner case at the boundary separating traditional from non-traditional responses.

Preconditions to Sending Non-traditional Responses A server may send multiple responses to a request if there is any property in the request that indicates the client's intention to receive them. This is typically indicated by a request option, and rarely in external properties of the message (in the multicast case, the destination address). A mechanism for eliciting multiple responses must specify the conditions under which a token gets freed, as the traditional arrival of the response is insufficient. It may also specify for which requests the token can be reused immediately in follow-up requests. On unordered transports, or when it's a client's follow-up request and not a response that terminates the token, the client needs to wait with reuse until no reordered non-traditional responses can be expected anymore. If a non-traditional response answers the original request, no further action is required (this is the case of observation: ordering is added on top of that to ensure that only the latest response is used). If the response does not answer the original request, it must be non-matching, either by an option introduced with the eliciting option or by a generic option like Response-For.

Responses Without Explicit Request Endpoints may agree out of band on a token (or other request-matching details). One way to do that is to agree on a "phantom request", which is a request that the client might have sent and the server assumes to have received, without it actually being sent between those endpoints. As tokens are managed by the client, that request needs to be generated by the client, or in close collaboration with the client (for example by the client allowing a third party to use a subset of its token values in order to set up non-traditional responses).

OSCORE Processing for Non-traditional Responses OSCORE is built with the general assumption that requests are processed into exactly one response. The specification contains explicit provisions for Observe requests (), and a whole protocol extension for multicast requests . OSCORE's binding between requests and responses remains unmodified: Each response is cryptographically bound to an OSCORE request. Therefore, any phantom request needs to be an OSCORE request as well, and the parties need to agree on the sender and sequence number of the phantom request. An easy way to do that securely is to deliver the phantom request in a way that the server can do the full OSCORE request processing on it. The server may process the OSCORE request into internal data structures at reception time, or may process it whenever a response is to be sent. In the latter case, it may need to relax the requirements of Section Verifying the Request of , item 3. To avoid reinventing the same rules as for Observe requests for any other non-traditional response, this document defines a set of processing instructions which can be referenced when specifying their options. These rules generalize Sections Protecting the Response and Verifying the Response of :

• In 8.3 step 3, "use the AEAD nonce from the request" is only an option once, i.e., after the sequence number expressed in that request was removed from the replay window. This option is usually taken in the first response, necessitating the use of encoded Sender Sequence Numbers in later responses. (Non-traditional responses such as Observe that indicate the order of responses by a sequence number may require that the request's nonce is used either in the first response or not at all.) CA: We could also just mandate the "either the first or never" behavior. It is unclear why one would delay sending the one response that has the least overhead, but that may be lack of imagination. An approach where instances can not generally be duplicated and are used at most once (as in an affine type system) can make this doable in a safe way. In the end it's a tradeoff between implementer flexibility and specification simplicity. As a convenient effect, this generalized rule also implies that when a server performs Appendix Replay Window of , it needs to use its own Partial IV for the nonce (which without this generalized rule necessitated a "MUST" statement in the appendix).

• In 8.4 between steps 5 and 6, the Sender Sequence Number of the response establishes an order in the received messages, which users of non-traditional responses may rely on. If an option specified that only the first response may use the request's nonce, then the one response that uses it is ordered before all other responses to the same request.

• If the handling of multiple responses is not idempotent, then at 8.4 step 5:
  • For responses that use a Sender Sequence Number from the server, the client consults the replay window before decryption, and removes its number from the replay window after successful decryption.
  • For responses that use the request's Sender Sequence Number, duplication is tracked for each request.
  As a simplification, applications that only process the latest response may track the latest sequence number for deduplication.
• In 8.4 step 8, the Option establishing the non-traditional responses may specify that error conditions processing a response are not fatal for the whole request. This should be done when an Option allows immediate follow-up requests. This is the case for the Observe option: When an observation is refreshed, a response encrypted with the earlier request's request_kid may still be in flight. That in-flight response will fail decryption, but responses generated after the server has received the refresh will be decryptable again.

Response-For Option: Response with Embedded Request A server can send a response to a request that it did not actually receive by embedding the request which the response answers in the response. The new option "Response-For" contains a request packaged as in . The response is then intended to serve as a response to this request. The Response-For Option

No.	C	U	N	R	Name	Format	Length	Default
TBD1	C	-	-	-	Response-For	opaque	0-1023	(none)

The CoAP Token becomes meaningless for this form of response; responses with embedded requests are therefore sent with a zero-length Token. (In essence, the "Response-For" option takes the place of the request the Token usually stands for.) Note that block-wise transfer is not available for CoAP Options, possibly limiting the size of the request that can be stored in a "Response-For" Option. The congestion control considerations for confirmable and non-confirmable messages apply unchanged.

Leisure-For-Responses Option: Indicating Readiness to Receive Multiple Responses This new option indicates a number expressed as a uint. It allows the server to send that number of non-traditional response messages in addition to the requested response. They are to be sent without undue delay after the original response. The Leisure-For-Responses Option

No.	C	U	N	R	Name	Format	Length	Default
TBD2		U	-		Leisure-For-Responses	uint	1-4	0

The option is elective, but unsafe for proxies (as the option would otherwise cause multiple responses to a proxy that expects only one and that needs to be a matching response). A proxy that chooses not to implement it may forward the request with the Leisure-For-Responses option removed. On its own, the option does not indicate which kind of additional responses the client would expect (though further elective proxy-safe no-cache-key options can be added on top of that to give better guidance), and the server may choose not to send any at all. Intermediaries may add or remove the option, and use incoming responses to populate their cache. They may serve additional responses from their cache, but in most cases the sensible course of action is to forward the additional responses the origin server sends. Use cases for Leisure-For-Responses include sending further blocks in a Block2 transfer (which are obviously non-matching and thus don't need a Response-For), or serving follow-up documents (a response containing a single link can be followed by a representation of the linked resource, which needs a Response-For header that indicates the URI).

IANA Considerations This specification adds the following option numbers to the CoAP Option Numbers registry of : Newly Registered CoAP Option Numbers

Number	Name	Reference
TBD1	Response-For	RFCthis
TBD2	Leisure-For-Responses	RFCthis

RFC-Editor: In the table, please replace TBD1 and TBD2 with the option number actually registered. Then, please delete this paragraph.

Security Considerations TBD The CoAP request/response mechanism allows the client to ascertain a level of authentication (not resistant though to on-path attackers unless the communication is protected) and freshness of the response: The Token echoed in the response shows that the responder had knowledge of the (fresh) request (). Responses with embedded requests can not be authenticated or checked for freshness this way. Their content therefore is less trustworthy than normal responses unless authenticated in another way (e.g., via ). Security considerations for configured requests are discussed in .

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. RISE AB Ericsson AB Ericsson AB Ericsson AB RISE AB This document defines the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of messages exchanged with the Constrained Application Protocol (CoAP) between members of a group, e.g., sent over IP multicast. In particular, the described protocol defines how OSCORE is used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and for protection of the corresponding CoAP responses. Group OSCORE also defines a pairwise mode where each member of the group can efficiently derive a symmetric pairwise key with each other member of the group for pairwise OSCORE communication. Group OSCORE can be used between endpoints communicating with CoAP or CoAP- mappable HTTP. IoTconsultancy.nl RISE AB The Constrained Application Protocol (CoAP) is a web transfer protocol for constrained devices and constrained networks. In a number of use cases, constrained devices often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This document specifies the use of CoAP for group communication, including the use of UDP/IP multicast as the default underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by use of the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained devices or networks that support CoAP. This document replaces and obsoletes RFC 7390, while it updates RFC 7252 and RFC 7641. There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252. This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. RISE AB IoTconsultancy.nl This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. RISE AB RISE AB Ericsson AB The Constrained Application Protocol (CoAP) allows clients to "observe" resources at a server and to receive notifications as unicast responses upon changes of the resource state. In some use cases, such as those based on publish-subscribe, it would be convenient for the server to send a single notification addressed to all the clients observing the same target resource. This document updates RFC7252 and RFC7641, and it defines how a server sends observe notifications as response messages over multicast, synchronizing all the observers of the same resource on the same shared Token value. Besides, this document defines how the security protocol Group Object Security for Constrained RESTful Environments (Group OSCORE) can be used to protect multicast notifications end-to- end between the server and the observer clients.

Coap Extensions Explained by Non-traditional Responses

Observation This section describes the Observe option in the terms of this document. It does not intend to update the original specification, merely to provide an alternative phrasing of its rules which may be useful for implementors, and which the authors believe to have the same effect. When Observe:0 is present in a request, this sets up non-traditional responses until either of the following conditions is met:

• A follow-up request on the same token carries an Observe:1 option. (This is primarily in here because; Observe:1 and No-Response:any could be combined; otherwise, the other conditions suffice).
• Any response does not carry an Observe option.
• Any response has a non-successful status.

Follow-up requests are limited to extending the request ETag set. Responses are obviously non-matching by their Observe option; each hop discards the Observe option for the purpose of caching and refreshes its cache with the most recent one as per the Observe value.

Responses to Multicast Requests As with observe, this just phrases the existing mechanism in the context of this generalization. When the destination address of a CoAP request is a multicast address, that token is valid for any member of that group (which, for the purpose of the client, is any server at all) on any port. (Except for that the implications of having received a multicast request still need to be followed, it might be seen as a template for creating a phantom request to any endpoint, if that suits the reader's mental model.) Responses can only be sent for up to the deployment's Leisure time (see ) plus the application's timeout (in proxy situations, this needs to be communicated explicitly in the Multicast-Timeout option of ).

Triangular Responses (Response-To) The Response-To option can be viewed as a shorthand notation for "Consider this a No-Response:any request, but take a copy of it, make it into a CoAP-over-UDP request with that particular address as a source and any address of yours as a response, and treat that as a phantom request". [ It may make sense to add an explicit return token, and include a No-Response option; that might allow it to be used even across proxies. ]

Other Current Documents is a straightforward application of the phantom requests (the concept was developed there); Leisure-For-Responses could help it around the topic of joining a multicast group securely through a proxy. seems to fit well with the concepts here as well, and might be simplified by it both in terminology and by replacing Response-Forwarding with Response-For(Proxy-Scheme, Uri-Host).

Response for Configured Request A request may reach the server using a different means than that used for the response. For instance, the request may be configured in the server. Without limiting generality, we speak about configured requests. The client MUST be cognizant of that configuration as the request uses a token from the token name space it controls.

Examples for Configured Requests

Example: Periodic Request A server may be configured to act on a configured request every day at 12:00.

Example: Event Driven Request A server may be configured to act on a configured request each time it reboots.

Example: Configured Observe A server may be configured with a GET request from a client that includes an Observe option with value 0. This means that the server will send updates to the state of the resource addressed by the GET request to the configured address of the client. The considerations of apply. How losing interest reflects back into the configuration and whether there is some form of error notification to the source of the configuration is out of scope of the present specification.

Multicast Responses A server MAY send a response to a multicast address. (This needs to be a response to a configured request as a normal request cannot be sent from a multicast address.) Note that, as the originator of a multicast response is a unicast address, the relaxation of matching rules described in does not apply. The token space in CoAP is owned by the client, which is identified by a transport endpoint (address/port). Here, the address is a multicast address, so the token name space is shared by all nodes joined to that multicast address. The assumption for multicast responses is that, for each multicast group, there is some form of management for the token space (and the port number) that everyone can participate in that needs to join that multicast group; the specific form of management is out of the scope of this specification. Note that this means that multicast responses MUST NOT be sent to unmanaged multicast addresses such as All CoAP Nodes (). Multicast responses are always non-confirmable. The congestion control considerations for non-confirmable multicast messages apply unchanged. provides a concrete way of communicating such a setup.

Respond-To Option: A Potential Common Component What has been called "configured request" here may also be triggered by a usual CoAP request that carries options that ask for modified response behavior. (The term "configured request" is still appropriate as the server ought to be configured to accept option of this kind; see .) For instance, if a single client wants to request a server to send the response to a specific multicast address, it can indicate this by including something like the "Respond-To" option sketched here. This contains an opaque string with the port number as a 16-bit number (in network byte order), followed by the IP address (4-byte IPv4 or 16-byte IPv6). A Potential Respond-To Option

No.	C	U	N	R	Name	Format	Length	Default
TBD later	C	U	-	-	Respond-To	opaque	6-18	(none)

(No allocation of an Option number is planned at this time.)

Security Considerations for Configured Requests (Clearly, multicast responses pose a potential for amplification, in particular if unverified sources can cause them via Respond-To. XXX Discuss how to mitigate.) A Respond-To option can be used to incite a server to send data to a third party. This ought not be done blindly, i.e., only with considered application assent.

List of Tables

:

:

:

:

Acknowledgements TBD