[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Network Working Group                                         C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Informational                         November 13, 2017
Expires: May 17, 2018


                  CoAP: Non-traditional response forms
                    draft-bormann-core-responses-00

Abstract

   In CoAP as defined by RFC 7252, responses are always unicast back to
   a client that posed a request.  The present memo describes two forms
   of responses that go beyond that model.  These descriptions are not
   intended as advocacy for adopting these approaches immediately, they
   are provided to point out potential avenues for development that
   would have to be carefully evaluated.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of




Bormann                   Expires May 17, 2018                  [Page 1]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Response with embedded request  . . . . . . . . . . . . . . .   3
   3.  Response for configured request . . . . . . . . . . . . . . .   3
     3.1.  Examples for configured requests  . . . . . . . . . . . .   3
     3.2.  Example: Periodic request . . . . . . . . . . . . . . . .   4
     3.3.  Example: Event driven request . . . . . . . . . . . . . .   4
     3.4.  Example: Configured observe . . . . . . . . . . . . . . .   4
     3.5.  Multicast responses . . . . . . . . . . . . . . . . . . .   4
     3.6.  Respond-To option . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In CoAP as defined by RFC 7252, responses are always unicast back to
   a client that posed a request.  A server may want to send a response
   to a request that it did not receive, may want to multicast a
   response, or both.

   The descriptions in this specification are not intended as advocacy
   for adopting these approaches immediately, they are provided to point
   out potential avenues for development that would have to be carefully
   evaluated.

1.1.  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 BCP
   14 [RFC2119] [RFC8174] 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 draft:




Bormann                   Expires May 17, 2018                  [Page 2]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


   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.

2.  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 option "Response-For" contains a request packaged as in
   Section 5.2 of [I-D.ietf-core-object-security].  The response is then
   intended to serve as a response to this request.

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

                     Table 1: The Response-For Option

   The CoAP Token becomes meaningless for this form of response;
   responses with embedded requests are therefore sent with an zero-
   length Token.  (In essence, the "Response-For" option takes the place
   of the request the Token usually stands for.)

   The congestion control considerations for confirmable and non-
   confirmable messages apply unchanged.

3.  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.

3.1.  Examples for configured requests







Bormann                   Expires May 17, 2018                  [Page 3]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


3.2.  Example: Periodic request

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

3.3.  Example: Event driven request

   A server may be configured to act on a configured request each time
   it reboots.

3.4.  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 Section 4.5 of [RFC7641] apply.  How losing
   interest reflects back into to configuration and whether there is
   some form of error notification to the source of the configuration is
   out of scope of the present specification.

3.5.  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 Section 8.2 of
   [RFC7252] 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 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 (Section 12.8 of
   [RFC7252]).

   Multicast responses are always non-confirmable.  The congestion
   control considerations for non-confirmable multicast messages apply
   unchanged.




Bormann                   Expires May 17, 2018                  [Page 4]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


3.6.  Respond-To option

   What has been called "configured request" here may also be triggered
   by a usual CoAP request that carries the Respond-To option.  (The
   term "configured request" is still appropriate as the server ought to
   be configured to accept this option; see Section 5.)

   If a single client wants to request a server to send the response to
   a specific multicast address, it can include the "Respond-To" option.
   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).

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

4.  IANA Considerations

   This draft adds the following option numbers to the CoAP Option
   Numbers registry of [RFC7252]:

                   +--------+--------------+-----------+
                   | Number | Name         | Reference |
                   +--------+--------------+-----------+
                   | TBD    | Response-For | RFCthis   |
                   | TBD    | Respond-To   | RFCthis   |
                   +--------+--------------+-----------+

                       Table 2: CoAP Option Numbers

5.  Security Considerations

   TBD

   (Clearly, multicast responses pose a potential for amplification, in
   particular if unverified sources can cause them via Respond-To.
   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.

   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:



Bormann                   Expires May 17, 2018                  [Page 5]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


   The Token echoed in the response shows that the responder had
   knowledge of the (fresh) request (Section 5.3.1 of [RFC7252]).
   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
   [I-D.ietf-core-object-security]).

6.  References

6.1.  Normative References

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-06 (work in
              progress), October 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.

Acknowledgements

   TBD

Author's Address








Bormann                   Expires May 17, 2018                  [Page 6]


Internet-Draft    CoAP: Non-traditional response forms     November 2017


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org











































Bormann                   Expires May 17, 2018                  [Page 7]