[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 draft-ietf-core-block

CoRE Working Group                                            C. Bormann
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Informational                          October 24, 2010
Expires: April 27, 2011


                        Sliced transfers in CoAP
                    draft-bormann-core-coap-block-01

Abstract

   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  CoAP is based on datagram transport, which limits the
   maximum size of resource representations that can be transferred
   without too much fragmentation.  A previous version of this draft
   defined the Block option.  The Block option provides a minimal way to
   transfer larger representations in a block-wise fashion.  It is
   currently documented in the WG draft draft-ietf-core-block-00.txt

   This short I-D attempts to pick up some recent discussion on the CoRE
   mailing list, and defines a more general, but also slightly more
   complex approach.  It is intended as an example for a complete design
   based on this discussion, to enable a rational assessment of the
   relative complexities.

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 http://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 April 27, 2011.

Copyright Notice

   Copyright (c) 2010 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



Bormann                  Expires April 27, 2011                 [Page 1]


Internet-Draft                 CoAP-sliced                  October 2010


   Provisions Relating to IETF Documents
   (http://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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Sliced transfers . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  The Continuation Options . . . . . . . . . . . . . . . . .  5
     2.2.  Using the Continuation Options . . . . . . . . . . . . . .  6
     2.3.  Option values for Continuation-request and
           Continuation-response  . . . . . . . . . . . . . . . . . .  7
     2.4.  The Message-Size option  . . . . . . . . . . . . . . . . .  8
   3.  The Size-Estimate option . . . . . . . . . . . . . . . . . . .  9
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     5.1.  Mitigating Amplification Attacks . . . . . . . . . . . . . 11
     5.2.  Exposing Server Internals in Continuation-response
           Values . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14




















Bormann                  Expires April 27, 2011                 [Page 2]


Internet-Draft                 CoAP-sliced                  October 2010


1.  Introduction

   The CoRE WG is tasked with standardizing an Application Protocol for
   Constrained Networks/Nodes, CoAP.  This protocol is intended to
   provide RESTful [REST] services not unlike HTTP [RFC2616], while
   reducing the complexity of implementation as well as the size of
   packets exchanged in order to make these services useful in a highly
   constrained network of themselves highly constrained nodes.

   This objective requires restraint in a number of sometimes
   conflicting ways:

   o  reducing implementation complexity in order to minimize code size,

   o  reducing message sizes in order to minimize the number of
      fragments needed for each message (in turn to maximize the
      probability of delivery of the message), the amount of
      transmission power needed and the loading of the limited-bandwidth
      channel,

   o  reducing requirements on the environment such as stable storage,
      good sources of randomness or user interaction capabilities.

   CoAP is based on datagram transports such as UDP, which limit the
   maximum size of resource representations that can be transferred
   without creating unreasonable levels of fragmentation.

   A previous version of this draft defined the Block option.  The Block
   option provides a minimal way to transfer larger representations in a
   block-wise fashion.  It is currently documented in a CoAP WG draft
   [I-D.ietf-core-block].

   Recent discussion on the CoRE mailing list centered around the
   limitations of the Block approach:

   o  Block is based on fixed block sizes and does not provide for
      semantic fragmentation of the resource representation.

   o  The choice of block sizes is limited to a power of two.

   o  For continuation transfers, the server only receives a numeric
      block number and a block size, which only enables it to operate in
      a stateless fashion if the resource representation can be
      naturally addressed on such block boundaries.

   o  The negotiation of the desirable message size is quite efficient,
      but may be simplistic.




Bormann                  Expires April 27, 2011                 [Page 3]


Internet-Draft                 CoAP-sliced                  October 2010


   This short I-D attempts to pick up this discussion and defines a more
   general, but also slightly more complex approach.  It is intended as
   an example for a complete design based on this discussion, to enable
   a rational assessment of the relative complexities.

1.1.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]
   and indicate requirement levels for compliant CoAP implementations.

   The term "byte" is used in its now customary sense as a synonym for
   "octet".





































Bormann                  Expires April 27, 2011                 [Page 4]


Internet-Draft                 CoAP-sliced                  October 2010


2.  Sliced transfers

   Not all resource representations will fit into a single link layer
   packet of a constrained network.  Using fragmentation (either at the
   adaptation layer or at the IP layer) to enable the transport of
   larger representations is possible up to the maximum size of the
   underlying datagram protocol (such as UDP), but the fragmentation/
   reassembly process loads the lower layers with conversation state
   that is better managed in the application layer.

   This specification proposes a set of CoAP options to enable _sliced_
   access to resource representations.  The overriding objective is to
   avoid creating conversation state at the server for sliced GET
   requests.  (It is impossible to fully avoid creating conversation
   state for POST/PUT, if the creation/replacement of resources is to be
   atomic; where that property is not needed, there is no need to create
   server conversation state in this case, either.)

   Implementation of the options defined in this draft is intended to be
   optional.  However, when one of the Continuation options is present
   in a CoAP message, it MUST be processed; therefore these options are
   identified as critical options.

   In contrast to the Block option, which provides a limited choice of
   block sizes and requires all the transfers for one single resource
   representation retrieval to be of the same size, the options defined
   in this draft enable a transfer to be structured into a sequence of
   arbitrarily-sized _slices_, which are of independent size and are
   only limited by the datagram size of the underlying transport as well
   as the slice size preferences of the communicating nodes.

2.1.  The Continuation Options

   When a representation is larger than can be comfortably transferred
   in a single UDP datagram, the Continuation options can be used to
   indicate a sliced transfer.  The value of both Continuation-request
   and Continuation-response options is an opaque sequence of bytes that
   is used to link up one slice transaction with the next in a sequence
   of transactions.

   A Continuation-request option in a request indicates that the current
   transaction is intended as a continuation of the previous transaction
   that provided the same value for the Continuation-response option in
   a response.

   Where a GET request is sliced up, the Continuation-response option in
   a response indicates that the slice(s) received so far are not the
   complete resource representation, but an initial prefix of the



Bormann                  Expires April 27, 2011                 [Page 5]


Internet-Draft                 CoAP-sliced                  October 2010


   representation.  Further bytes of the representation can be retrieved
   by supplying the value of the Continuation-response option returned
   in the Continuation-request option of another request that otherwise
   looks like a GET request.

   (TBD: Does the continuation request have to supply the URI and other
   parameters again along with the Continuation-request option, or does
   the server make sure the Continuation-response provides all
   information required, e.g., by sending back a descriptor or by
   encoding the request parameters in the Continuation-response?)

   Each continuation response in a sliced transfer carries the response
   code that, based on information currently available, the server
   expects the transfer to receive at the end of the entire sequence of
   slices, e.g. a 200 code (encoded as 80 decimal) for a successful
   resource representation retrieval.  However, only the response code
   of the last slice transferred (i.e., without a Continuation-response
   option) is binding.

2.2.  Using the Continuation Options

   Using the Continuation options, a single REST operation can be split
   into multiple CoAP message transactions.  Each of these message
   transactions uses their own CoAP transaction ID.

   For synchronous responses, the Continuation-request option does not
   need to be repeated in the response.  For an asynchronous response,
   the server provides both the Continuation-request option and, if
   applicable, the Continuation-response option.

   For GET requests, the server simply adds the Continuation-response
   option to any response for which it is unable or unwilling to include
   the entire resource representation.  The client then echoes back the
   value of the Continuation-response in the value of a Continuation-
   request option.  The response carrying the last slice of the
   representation simply does not contain a Continuation-response
   option; it is distinguishable from a response carrying the entire
   resource representation by the presence of Continuation-request in
   the related request (synchronous) or in the response (asynchronous).

   For PUT and POST requests, a client has to indicate that it requests
   a Continuation-response option from the server whenever it is unable
   or unwilling to provide the entire (rest of the) representation in
   the current transaction, i.e. that the slice(s) transferred so far
   are only a prefix of the entire representation to be transferred.
   This is done by supplying a Continuation-required option in the
   request.  The request that carries the last slice of the
   representation does not contain a Continuation-required option.



Bormann                  Expires April 27, 2011                 [Page 6]


Internet-Draft                 CoAP-sliced                  October 2010


   However, the response to that last forward-transferring request may
   carry a Continuation-response option, in case the representation
   returned from the PUT or POST request is larger than can be
   comfortably transferred in one message.  The exchange then continues
   as it would for a sliced GET request.

2.3.  Option values for Continuation-request and Continuation-response

   The structure of the values provided by the server in a Continuation-
   response option (and echoed back by the client in a Continuation-
   request option) is not defined by the protocol.  The structure of the
   value is opaque to the client and entirely determined by the server.
   In particular, the client is not permitted to manipulate or "make up"
   Continuation-request values.

   For a stateless server, the structure of the value will be chosen to
   enable generating the next slice.  E.g., for a server enumerating
   devices, the value might be an identifier for the last device
   described in the last slice.

   In order to increase the debuggability of the protocol, there is a
   suggested structure that can (but need not be) be used whenever it is
   a good fit.  This structure only works when all slices in a transfer
   (except for the last) use the same slice size, which also is a power
   of two.  If the structure is used, the value of the Continuation-
   request and Continuation-response options is a sequence of bytes
   representing an unsigned integer, the three least significant bits of
   which indicate the size of all slices used in the transfer.  The
   value divided by eight is the number of the slice the Continuation-
   response pertains to, starting from zero, i.e., the response is about
   the "size" bytes starting at byte "blocknr << (szx + 3)"; note that
   the value of the Continuation-request option in the next request
   echoes the number of the previously transferred block.


















Bormann                  Expires April 27, 2011                 [Page 7]


Internet-Draft                 CoAP-sliced                  October 2010


           0
           0 1 2 3 4 5 6 7
          +-+-+-+-+-+-+-+-+
          | blocknr | szx |
          +-+-+-+-+-+-+-+-+

           0                   1
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |         block nr        | szx |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           0                   1                   2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                 block nr                | szx |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 1: Suggested structure of the Continuation option values for
                    block-wise transfers, if applicable

2.4.  The Message-Size option

   To influence the slice size used in response to a GET request, the
   requester uses the (elective) Message-Size option, giving the desired
   maximum size of a message.  A server SHOULD use the slice size
   indicated or a smaller size.

   To influence the slice size used in a PUT or POST request, the server
   can provide an (elective) Message-Size option in its first response.
   For the continuation requests, the client SHOULD use the slice size
   indicated or a smaller size.  Since there is no way for the server to
   influence the size of the first message, the slice carried in this
   message should be kept reasonably small (e.g., a size that is
   commensurate with the overhead of the request or even zero bytes in
   size).  A client MAY cache Message-Size options received from a
   server and use the cached value as a hint for future PUT or POST
   transactions to that server.













Bormann                  Expires April 27, 2011                 [Page 8]


Internet-Draft                 CoAP-sliced                  October 2010


3.  The Size-Estimate option

   (This is new functionality not provided by the Block option.)

   The party slicing up a resource representation for sliced transfer
   may have an idea of the size of the entire resource representation in
   bytes.  Providing this size as an estimate may be beneficial for the
   other party.  If provided, it should be sent with the first slice,
   and SHOULD provide a close upper bound of the total size that will be
   transferred.  In a PUT or POST transfer, both sides MAY provide a
   Size-Estimate for their respective resource representation to be
   transferred.







































Bormann                  Expires April 27, 2011                 [Page 9]


Internet-Draft                 CoAP-sliced                  October 2010


4.  IANA Considerations

   This draft adds the following option numbers to Table 2 of
   [I-D.ietf-core-coap]:

   +-----+----+--------------------+----------------+--------+---------+
   | Typ | C/ | Name               | Data type      | Length | Default |
   |   e | E  |                    |                |        |         |
   +-----+----+--------------------+----------------+--------+---------+
   |  16 | E  | Message-Size       | Variable-lengt | 1-2 B  | (none)  |
   |     |    |                    | h unsigned     |        |         |
   |     |    |                    | integer        |        |         |
   |     |    |                    |                |        |         |
   |  17 | C  | Continuation-reque | Opaque String  | (any)  | (none)  |
   |     |    | st                 | of Bytes       |        |         |
   |     |    |                    |                |        |         |
   |  18 | E  | Size-Estimate      | Variable-lengt | 1-4 B  | (none)  |
   |     |    |                    | h unsigned     |        |         |
   |     |    |                    | integer        |        |         |
   |     |    |                    |                |        |         |
   |  19 | C  | Continuation-respo | Opaque String  | (any)  | (none)  |
   |     |    | nse                | of Bytes       |        |         |
   |     |    |                    |                |        |         |
   |  21 | C  | Continuation-requi | (none)         | 0      | (none)  |
   |     |    | red                |                |        |         |
   +-----+----+--------------------+----------------+--------+---------+

























Bormann                  Expires April 27, 2011                [Page 10]


Internet-Draft                 CoAP-sliced                  October 2010


5.  Security Considerations

   TBD.  (Weigh the security implications of application layer sliced
   transfer against those of adaptation-layer or IP-layer
   fragmentation.)

5.1.  Mitigating Amplification Attacks

   TBD.  (This section discusses how CoAP nodes could become implicated
   in DoS attacks by using the amplifying properties of the protocol, as
   well as mitigations for this threat.)

   A CoAP server can reduce the amount of amplification it provides to
   an attacker by offering large resource representations only in
   relatively small slices.  E.g., for a 1000 byte resource, a 10-byte
   request might result in an 80-byte response (with a 64-byte block)
   instead of a 1016-byte response, considerably reducing the
   amplification provided.

5.2.  Exposing Server Internals in Continuation-response Values

   The server should be careful about the values exposed in
   Continuation-response options:

   o  An attacker might be able to derive information from the value
      that the server did not intend to make available, such as row
      numbers in an internal database.  This can be mitigated by
      encrypting the value with a secret only known to the server.

   o  An attacker might attempt to forge Continuation-response values to
      obtain increased access.  Where the structure of the Continuation-
      response might make this possible, the server should validate it
      e.g. by including an HMAC computed from a secret only known to the
      server.  If replay attacks might be problem, the server should
      mitigate them, e.g. by adding a timestamp or a sequence number
      into the protected data.















Bormann                  Expires April 27, 2011                [Page 11]


Internet-Draft                 CoAP-sliced                  October 2010


6.  Acknowledgements

   As mentioned, much of the content of this draft is the result of
   discussions within the CoRE mailing list, in particular with Robert
   Quattlebaum (who insisted on variable-length semantic fragmentation)
   and Peter Bigot.













































Bormann                  Expires April 27, 2011                [Page 12]


Internet-Draft                 CoAP-sliced                  October 2010


7.  References

7.1.  Normative References

   [I-D.ietf-core-coap]
              Shelby, Z., Frank, B., and D. Sturek, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-02
              (work in progress), September 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

7.2.  Informative References

   [I-D.ietf-core-block]
              Shelby, Z. and C. Bormann, "Blockwise transfers in CoAP",
              draft-ietf-core-block-00 (work in progress), October 2010.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", 2000.



























Bormann                  Expires April 27, 2011                [Page 13]


Internet-Draft                 CoAP-sliced                  October 2010


Author's Address

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

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








































Bormann                  Expires April 27, 2011                [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/