--- 1/draft-ietf-core-block-18.txt 2016-03-21 11:24:24.049020949 -0700 +++ 2/draft-ietf-core-block-19.txt 2016-03-21 11:24:24.365028857 -0700 @@ -1,19 +1,19 @@ CoRE Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track Z. Shelby, Ed. -Expires: March 17, 2016 ARM - September 14, 2015 +Expires: September 22, 2016 ARM + March 21, 2016 Block-wise transfers in CoAP - draft-ietf-core-block-18 + draft-ietf-core-block-19 Abstract CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive @@ -45,25 +45,25 @@ 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 March 17, 2016. + This Internet-Draft will expire on September 22, 2016. 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. This document is subject to BCP 78 and the IETF Trust's Legal 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 @@ -85,30 +85,30 @@ 2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15 2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15 2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15 2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16 3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20 3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 21 3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 23 4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 26 - 5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 27 + 5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 28 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 30 7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 31 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP protocol is intended to provide RESTful [REST] services not unlike HTTP [RFC7230], while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services @@ -198,24 +198,25 @@ 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 for 6LoWPAN [RFC4919]) When a resource representation is larger than can be comfortably 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 sent both with requests and with responses, this specification 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, - and the number 2 to refer to the transfer of the resource - representation for the response. + and the number 2 ("Block2", "Size2") to refer to the transfer of the + resource representation for the response. In the following, the term "payload" will be used for the actual content of a single CoAP message, i.e. a single block being transferred, while the term "body" will be used for the entire resource representation that is being transferred in a block-wise fashion. The Content-Format option applies to the body, not to the payload, in particular the boundaries between the blocks may be in places that are not separating whole units in terms of the structure, encoding, or content-coding used by the Content-Format. @@ -576,23 +577,23 @@ (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 sequence from the same endpoint was finished) simply overwrites the context the server may still be keeping. (This is probably exactly what one wants in this case - the client may simply have restarted and lost its knowledge of the previous sequence.) 2.6. Combining Block-wise Transfers with the Observe Option 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 - observed by clients may be larger than can be comfortably processed - or transferred in one CoAP message. The following rules apply to the + changes over time of a resource [RFC7641]. Resources observed by + clients may be larger than can be comfortably processed or + transferred in one CoAP message. The following rules apply to the combination of block-wise transfers with notifications. Observation relationships always apply to an entire resource; the Block2 option does not provide a way to observe a single block of a resource. As with basic GET transfers, the client can indicate its desired block size in a Block2 Option in the GET request establishing or renewing the observation relationship. If the server supports block- wise transfers, it SHOULD take note of the block size and apply it as @@ -726,26 +727,28 @@ retransmissions, and examples for the operation of the block size negotiation. 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 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 would be shown as 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128. + As in [RFC7252], "MID" is used as an abbreviation of "Message ID". + 3.1. Block2 Examples 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 - client agrees. The first two ACKs contain 128 bytes of payload each, - and third ACK contains between 1 and 128 bytes. + client agrees. The first two ACKs contain a payload of 128 bytes + each, and the third ACK contains a payload between 1 and 128 bytes. CLIENT SERVER | | | CON [MID=1234], GET, /status ------> | | | | <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 | | | | CON [MID=1235], GET, /status, 2:1/0/128 ------> | | | | <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 | @@ -1147,23 +1150,26 @@ In many cases when transferring a large resource representation block by block, it is advantageous to know the total size early in the process. Some indication may be available from the maximum size estimate attribute "sz" provided in a resource description [RFC6690]. However, the size may vary dynamically, so a more up-to-date indication may be useful. This specification defines two CoAP Options, Size1 for indicating the size of the representation transferred in requests, and Size2 for 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 - 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: o in a request, to ask the server to provide a size estimate along with the usual response ("size request"). For this usage, the value MUST be set to 0. o in a response carrying a Block2 Option, to indicate the current estimate the server has of the total size of the resource representation, measured in bytes ("size indication"). @@ -1319,21 +1325,27 @@ from IP fragmentation and TCP segmentation; CoAP does not add fundamentally new considerations. Where access to a resource is only granted to clients making use of specific security associations, all blocks of that resource MUST be subject to the same security checks; it MUST NOT be possible for unprotected exchanges to influence blocks of an otherwise protected resource. As a related consideration, where object security is employed, PUT/POST should be implemented in the atomic fashion, 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 adversary sends a Block1 (e.g., PUT) block with a high block number: A naive implementation might exhaust its resources by creating a huge resource representation. Misleading size indications may be used by an attacker to induce buffer overflows in poor implementations, for which the usual considerations apply. @@ -1384,85 +1396,88 @@ the [RFC7252] authors, and via many CoRE WG discussions. Charles Palmer provided extensive editorial comments to a previous version of this draft, some of which the authors hope to have covered in this version. Esko Dijk reviewed a more recent version, leading to a number of further editorial improvements, a solution to the 4.13 ambiguity problem, and the section about combining Block and multicast. Markus Becker proposed getting rid of an ill-conceived default value for the Block2 and Block1 options. Peter Bigot 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 the Size Option, which has informed this draft. Klaus Hartke wrote some of the text describing the interaction of Block2 with Observe. Matthias Kovatsch provided a number of significant simplifications of the protocol. 9. 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 - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained - Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ - RFC7252, June 2014, + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, . + [RFC7641] Hartke, K., "Observing Resources in the Constrained + Application Protocol (CoAP)", RFC 7641, + DOI 10.17487/RFC7641, September 2015, + . + 9.2. Informative References [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): - Overview, Assumptions, Problem Statement, and Goals", RFC - 4919, DOI 10.17487/RFC4919, August 2007, + Overview, Assumptions, Problem Statement, and Goals", + RFC 4919, DOI 10.17487/RFC4919, August 2007, . [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, . [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained-Node Networks", RFC 7228, DOI 10.17487/ - RFC7228, May 2014, + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Message Syntax and Routing", RFC - 7230, DOI 10.17487/RFC7230, June 2014, + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, . Authors' Addresses + Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Zach Shelby (editor)