draft-ietf-core-block-18.txt   draft-ietf-core-block-19.txt 
CoRE Working Group C. Bormann CoRE Working Group C. Bormann
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Standards Track Z. Shelby, Ed. Intended status: Standards Track Z. Shelby, Ed.
Expires: March 17, 2016 ARM Expires: September 22, 2016 ARM
September 14, 2015 March 21, 2016
Block-wise transfers in CoAP Block-wise transfers in CoAP
draft-ietf-core-block-18 draft-ietf-core-block-19
Abstract Abstract
CoAP is a RESTful transfer protocol for constrained nodes and CoAP is a RESTful transfer protocol for constrained nodes and
networks. Basic CoAP messages work well for the small payloads we networks. Basic CoAP messages work well for the small payloads we
expect from temperature sensors, light switches, and similar expect from temperature sensors, light switches, and similar
building-automation devices. Occasionally, however, applications building-automation devices. Occasionally, however, applications
will need to transfer larger payloads -- for instance, for firmware will need to transfer larger payloads -- for instance, for firmware
updates. With HTTP, TCP does the grunt work of slicing large updates. With HTTP, TCP does the grunt work of slicing large
payloads up into multiple packets and ensuring that they all arrive payloads up into multiple packets and ensuring that they all arrive
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 March 17, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 50 skipping to change at page 2, line 50
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15 2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15 2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15 2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15 2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16 3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20 3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20
3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 21 3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 21
3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 23 3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 23
4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 26 4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 26
5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 27 5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 30 7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 30
7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 31 7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 31
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 31 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
The work on Constrained RESTful Environments (CoRE) aims at realizing The work on Constrained RESTful Environments (CoRE) aims at realizing
the REST architecture in a suitable form for the most constrained the REST architecture in a suitable form for the most constrained
nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) nodes (such as microcontrollers with limited RAM and ROM [RFC7228])
and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP
protocol is intended to provide RESTful [REST] services not unlike protocol is intended to provide RESTful [REST] services not unlike
HTTP [RFC7230], while reducing the complexity of implementation as HTTP [RFC7230], while reducing the complexity of implementation as
well as the size of packets exchanged in order to make these services well as the size of packets exchanged in order to make these services
skipping to change at page 5, line 22 skipping to change at page 5, line 22
o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6) o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)
o by the desire to avoid adaptation layer fragmentation (60-80 bytes o by the desire to avoid adaptation layer fragmentation (60-80 bytes
for 6LoWPAN [RFC4919]) for 6LoWPAN [RFC4919])
When a resource representation is larger than can be comfortably When a resource representation is larger than can be comfortably
transferred in the payload of a single CoAP datagram, a Block option transferred in the payload of a single CoAP datagram, a Block option
can be used to indicate a block-wise transfer. As payloads can be can be used to indicate a block-wise transfer. As payloads can be
sent both with requests and with responses, this specification sent both with requests and with responses, this specification
provides two separate options for each direction of payload transfer. provides two separate options for each direction of payload transfer.
In identifying these options, we use the number 1 to refer to the In naming these options (for block-wise transfers as well as in
Section 4), we use the number 1 ("Block1", "Size1") to refer to the
transfer of the resource representation that pertains to the request, transfer of the resource representation that pertains to the request,
and the number 2 to refer to the transfer of the resource and the number 2 ("Block2", "Size2") to refer to the transfer of the
representation for the response. resource representation for the response.
In the following, the term "payload" will be used for the actual In the following, the term "payload" will be used for the actual
content of a single CoAP message, i.e. a single block being content of a single CoAP message, i.e. a single block being
transferred, while the term "body" will be used for the entire transferred, while the term "body" will be used for the entire
resource representation that is being transferred in a block-wise resource representation that is being transferred in a block-wise
fashion. The Content-Format option applies to the body, not to the fashion. The Content-Format option applies to the body, not to the
payload, in particular the boundaries between the blocks may be in payload, in particular the boundaries between the blocks may be in
places that are not separating whole units in terms of the structure, places that are not separating whole units in terms of the structure,
encoding, or content-coding used by the Content-Format. encoding, or content-coding used by the Content-Format.
skipping to change at page 13, line 27 skipping to change at page 13, line 27
(e.g., PUT or POST) operations to the same resource. Starting a new (e.g., PUT or POST) operations to the same resource. Starting a new
block-wise sequence of requests to the same resource (before an old block-wise sequence of requests to the same resource (before an old
sequence from the same endpoint was finished) simply overwrites the sequence from the same endpoint was finished) simply overwrites the
context the server may still be keeping. (This is probably exactly context the server may still be keeping. (This is probably exactly
what one wants in this case - the client may simply have restarted what one wants in this case - the client may simply have restarted
and lost its knowledge of the previous sequence.) and lost its knowledge of the previous sequence.)
2.6. Combining Block-wise Transfers with the Observe Option 2.6. Combining Block-wise Transfers with the Observe Option
The Observe Option provides a way for a client to be notified about The Observe Option provides a way for a client to be notified about
changes over time of a resource [I-D.ietf-core-observe]. Resources changes over time of a resource [RFC7641]. Resources observed by
observed by clients may be larger than can be comfortably processed clients may be larger than can be comfortably processed or
or transferred in one CoAP message. The following rules apply to the transferred in one CoAP message. The following rules apply to the
combination of block-wise transfers with notifications. combination of block-wise transfers with notifications.
Observation relationships always apply to an entire resource; the Observation relationships always apply to an entire resource; the
Block2 option does not provide a way to observe a single block of a Block2 option does not provide a way to observe a single block of a
resource. resource.
As with basic GET transfers, the client can indicate its desired As with basic GET transfers, the client can indicate its desired
block size in a Block2 Option in the GET request establishing or block size in a Block2 Option in the GET request establishing or
renewing the observation relationship. If the server supports block- renewing the observation relationship. If the server supports block-
wise transfers, it SHOULD take note of the block size and apply it as wise transfers, it SHOULD take note of the block size and apply it as
skipping to change at page 16, line 32 skipping to change at page 16, line 32
retransmissions, and examples for the operation of the block size retransmissions, and examples for the operation of the block size
negotiation. negotiation.
In all these examples, a Block option is shown in a decomposed way In all these examples, a Block option is shown in a decomposed way
indicating the kind of Block option (1 or 2) followed by a colon, and indicating the kind of Block option (1 or 2) followed by a colon, and
then the block number (NUM), more bit (M), and block size exponent then the block number (NUM), more bit (M), and block size exponent
(2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33 (2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33
would be shown as 2:2/0/32), or a Block1 Option value of 59 would be would be shown as 2:2/0/32), or a Block1 Option value of 59 would be
shown as 1:3/1/128. shown as 1:3/1/128.
As in [RFC7252], "MID" is used as an abbreviation of "Message ID".
3.1. Block2 Examples 3.1. Block2 Examples
The first example (Figure 2) shows a GET request that is split into The first example (Figure 2) shows a GET request that is split into
three blocks. The server proposes a block size of 128, and the three blocks. The server proposes a block size of 128, and the
client agrees. The first two ACKs contain 128 bytes of payload each, client agrees. The first two ACKs contain a payload of 128 bytes
and third ACK contains between 1 and 128 bytes. each, and the third ACK contains a payload between 1 and 128 bytes.
CLIENT SERVER CLIENT SERVER
| | | |
| CON [MID=1234], GET, /status ------> | | CON [MID=1234], GET, /status ------> |
| | | |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| | | |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> | | CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| | | |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 | | <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
skipping to change at page 26, line 33 skipping to change at page 26, line 33
In many cases when transferring a large resource representation block In many cases when transferring a large resource representation block
by block, it is advantageous to know the total size early in the by block, it is advantageous to know the total size early in the
process. Some indication may be available from the maximum size process. Some indication may be available from the maximum size
estimate attribute "sz" provided in a resource description [RFC6690]. estimate attribute "sz" provided in a resource description [RFC6690].
However, the size may vary dynamically, so a more up-to-date However, the size may vary dynamically, so a more up-to-date
indication may be useful. indication may be useful.
This specification defines two CoAP Options, Size1 for indicating the This specification defines two CoAP Options, Size1 for indicating the
size of the representation transferred in requests, and Size2 for size of the representation transferred in requests, and Size2 for
indicating the size of the representation transferred in responses. indicating the size of the representation transferred in responses.
(Size1 is already defined in [RFC7252] for the narrow case of (Size1 has already been defined in Section 5.10.9 of [RFC7252] to
provide "size information about the resource representation in a
request", however that section only details the narrow case of
indicating in 4.13 responses the maximum size of request payload that indicating in 4.13 responses the maximum size of request payload that
the server is able and willing to handle.) the server is able and willing to handle. The present specification
provides details about its use as a request option as well.)
The Size2 Option may be used for two purposes: The Size2 Option may be used for two purposes:
o in a request, to ask the server to provide a size estimate along o in a request, to ask the server to provide a size estimate along
with the usual response ("size request"). For this usage, the with the usual response ("size request"). For this usage, the
value MUST be set to 0. value MUST be set to 0.
o in a response carrying a Block2 Option, to indicate the current o in a response carrying a Block2 Option, to indicate the current
estimate the server has of the total size of the resource estimate the server has of the total size of the resource
representation, measured in bytes ("size indication"). representation, measured in bytes ("size indication").
skipping to change at page 30, line 12 skipping to change at page 30, line 18
from IP fragmentation and TCP segmentation; CoAP does not add from IP fragmentation and TCP segmentation; CoAP does not add
fundamentally new considerations. fundamentally new considerations.
Where access to a resource is only granted to clients making use of Where access to a resource is only granted to clients making use of
specific security associations, all blocks of that resource MUST be specific security associations, all blocks of that resource MUST be
subject to the same security checks; it MUST NOT be possible for subject to the same security checks; it MUST NOT be possible for
unprotected exchanges to influence blocks of an otherwise protected unprotected exchanges to influence blocks of an otherwise protected
resource. As a related consideration, where object security is resource. As a related consideration, where object security is
employed, PUT/POST should be implemented in the atomic fashion, employed, PUT/POST should be implemented in the atomic fashion,
unless the object security operation is performed on each access and unless the object security operation is performed on each access and
the creation of unusable resources can be tolerated. the creation of unusable resources can be tolerated. Future end-to-
end security mechanisms that may be added to CoAP itself may have
related security considerations, this includes considerations about
caching of blocks in clients and in proxies (see Section 2.10 and
Section 5 for different strategies in performing this caching); these
security considerations will need to be described in the
specifications of those mechanisms.
A stateless server might be susceptible to an attack where the A stateless server might be susceptible to an attack where the
adversary sends a Block1 (e.g., PUT) block with a high block number: adversary sends a Block1 (e.g., PUT) block with a high block number:
A naive implementation might exhaust its resources by creating a huge A naive implementation might exhaust its resources by creating a huge
resource representation. resource representation.
Misleading size indications may be used by an attacker to induce Misleading size indications may be used by an attacker to induce
buffer overflows in poor implementations, for which the usual buffer overflows in poor implementations, for which the usual
considerations apply. considerations apply.
skipping to change at page 31, line 30 skipping to change at page 31, line 42
the [RFC7252] authors, and via many CoRE WG discussions. the [RFC7252] authors, and via many CoRE WG discussions.
Charles Palmer provided extensive editorial comments to a previous Charles Palmer provided extensive editorial comments to a previous
version of this draft, some of which the authors hope to have covered version of this draft, some of which the authors hope to have covered
in this version. Esko Dijk reviewed a more recent version, leading in this version. Esko Dijk reviewed a more recent version, leading
to a number of further editorial improvements, a solution to the 4.13 to a number of further editorial improvements, a solution to the 4.13
ambiguity problem, and the section about combining Block and ambiguity problem, and the section about combining Block and
multicast. Markus Becker proposed getting rid of an ill-conceived multicast. Markus Becker proposed getting rid of an ill-conceived
default value for the Block2 and Block1 options. Peter Bigot default value for the Block2 and Block1 options. Peter Bigot
insisted on a more systematic coverage of the options and response insisted on a more systematic coverage of the options and response
code. code. Qin Wu provided a review for the IETF Operational directorate,
and Goeran Selander commented on the security considerations.
Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of
the Size Option, which has informed this draft. Klaus Hartke wrote the Size Option, which has informed this draft. Klaus Hartke wrote
some of the text describing the interaction of Block2 with Observe. some of the text describing the interaction of Block2 with Observe.
Matthias Kovatsch provided a number of significant simplifications of Matthias Kovatsch provided a number of significant simplifications of
the protocol. the protocol.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-16 (work in progress), December 2014.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252,
RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>.
9.2. Informative References 9.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation, Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000, University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC Overview, Assumptions, Problem Statement, and Goals",
4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>. <http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <http://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/ Constrained-Node Networks", RFC 7228,
RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
[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", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
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>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>. <http://www.rfc-editor.org/info/rfc7233>.
Authors' Addresses Authors' Addresses
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Zach Shelby (editor) Zach Shelby (editor)
 End of changes. 24 change blocks. 
35 lines changed or deleted 50 lines changed or added

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