CORE WG Z. Cao INTERNET-DRAFT R. Jadhav Intended Status: Informational Huawei Expires: April 26, 2016 October 27, 2016 CoAP Delegated Observe draft-cao-core-delegated-observe-00 Abstract This document discusses the scenarios for "delegated observe", in which a subscriber needs to register some resources on behalf of some other entities. This document also presents a CoAP protocol extension for the delegated observe operation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Zhen Cao, et al. Expires [Page 1] INTERNET DRAFT draft-cao-core-delegated-observe Copyright and License Notice 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 described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Scenarios for Delegated Observe . . . . . . . . . . . . . . . . 3 2.1 Multiple Devices . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Delegation to Cloud . . . . . . . . . . . . . . . . . . . . 3 2.3 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Overview of Delegated Observe . . . . . . . . . . . . . . . . . 4 4 The Delegated Observe Option . . . . . . . . . . . . . . . . . . 5 5 Handling Delegated Observe . . . . . . . . . . . . . . . . . . 6 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Zhen Cao, et al. Expires [Page 2] INTERNET DRAFT draft-cao-core-delegated-observe 1 Introduction CoAP [RFC7252] is a light-weight application protocol for constrained networks. To avoid keeping polling devices, CoAP supports the 'observe' operation defined in [RFC7641], in which a subscriber can register its interest to certain resources and then be updated with their representation. However, in the current "observe" protocol, the subscriber can only register interests on behalf of itself, and therefore, updated information of the represented resources could not be notified to any parties other than the one who sends the observe request. This document discusses the scenarios for "delegated observation", in which a subscriber needs to register some resources on behalf of other entities or a group of entities including itself. This document also presents a CoAP protocol extension for the delegated observe operation. 2 Scenarios for Delegated Observe This section describes scenarios that needs delegated observe. 2.1 Multiple Devices In a typical smart home network setup, a user with multiple devices wants to observe some sensor resource (e.g., thermometer, bulbs). Instead of sending CoAP Observe requests from every single device, one of the them can send an Observe Registration on behalf of that group of devices, so that all of them will be notified at once. 2.2 Delegation to Cloud A user wants its mobile device to be notified of a certain sensor information both in-home and off-home. When the device moves out of its smart home network coverage, it is normally hidden behind NAT and FW that keep it being reached for such notification messages. In this case, the normal observe-notification scheme may fail. A walk- around for this case is to let the device send a delegated observe request while at home, asking the home sensors send notifications to the device's representative cloud server, so that the device can always fetch the information from it cloud service while off-home. This scenario is depicted in Fig. 1. Zhen Cao, et al. Expires [Page 3] INTERNET DRAFT draft-cao-core-delegated-observe dev Cloud dev Sensor in-home Server off-home | | | | | Delegated | | | |<--Observe --| | | | | | | |--------Notification-------->| | | | | | |<-- GET--------| | |----- ACK----->| Figure 1: Delegation to Cloud 2.3 Multicast A group of devices would like to observe the location information on a motion sensor. This is a useful case when a number of light bulbs need to adjust its lighting intensity based on the location of the observed motion object. Instead of let each device register an interest on the motion sensor, one of them could simply delegate the observe to this multicast group, so that the location update notifications will be send to the multicast address that they belong to. This scenario is visualized in Fig.2. Motion Sensor Bulb_1 Bulb_2 Bulb_n | | | | | Delegated | | | |<-Observe-----| | | | | | | | Multicast | | | |--Notify ---->|----------->|----------->| | | | | | | | | Figure 2: Delegation to a Multicast Group 3 Overview of Delegated Observe As show in Fig.3, we name the node that has the direct representation of the CoAP resource as the "Source node"; and the immediate node as the 'Delegate node' that will send delegated Observe request to the Source node, on behalf of the "Delegated node" who will be notified by the Source Node. Zhen Cao, et al. Expires [Page 4] INTERNET DRAFT draft-cao-core-delegated-observe Source Delegate Delegated Node Node Node | | | | Delegated | | |<-Observe-----| | | | | | | | |--Notify ---->|----------->| | | | | | | Figure 3: Overview of Delegated Observe 4 The Delegated Observe Option The properties of the Delegated Observe Option are defined in Fig. 4. In a GET request: +-----+---+---+---+---+------------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+------------------+--------+--------+---------+ | TBD | | x | - | | Delegated Observe| string | 0-256 | (none) | +-----+---+---+---+---+------------------+--------+--------+---------+ C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable In a Response: +-----+---+---+---+---+------------------+--------+--------+---------+ | No. | C | U | N | R | Name | Format | Length | Default | +-----+---+---+---+---+------------------+--------+--------+---------+ | TBD | | x | - | | Delegated Observe| uint | 0-3 B | (none) | +-----+---+---+---+---+------------------+--------+--------+---------+ C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable Figure 4: CoAP Delegated Observe Option When included in a GET request, the Delegated Observe Option extends the GET method so it does not only retrieve a current representation of the target resource, but also requests the server to add an entry in the list of observers of the resource. This entry maps the target resource to an identifier of the observer contained in the value of this option. When used to register the representation, the value of Delegated Observe in a GET request is the identifier of the nodes that will be notified, in the format of "IP:port" or "domain_name:port". When used to de-register the representation, the value of Delegated Zhen Cao, et al. Expires [Page 5] INTERNET DRAFT draft-cao-core-delegated-observe Observe in the GET is a special string, e.g., in the format of ":::", the specific format needs further discussion. [TBD] When included in a response, the Delegated Observe Option identifies the message as a notification. The Option value is used as a sequence number used to infer the order of the notifications. The ordering inference is the same as what has been discussed in Section 3.4 of [RFC7641]. 5 Handling Delegated Observe Before sending the delegated observe, the "Delegate node" needs to know which address:port on the Delegated node will be open to receive the subsequent notification from the source node. This negotiation is out of scope of this document. Upon receiving the delegated observe request, the "Source Node" will create an entry based on the identifier of the Delegated Node contained within the request. The Source Node can decide if it needs to verify the validity of the Delegated node, per its own policy. The validation way is also out of the scope of this document. The Delegated Node, once being delegated and verified by Source Node, will be notified subsequently, although it does not send the request for that resource. The Delegated Node interprets the CoAP message, and will handle this message if the CoAP message contains a Delegated Observe option defined in Section 4. 6 Security Considerations The security considerations in [RFC7252] and [RFC7641] apply. Delegated observe may increase the risk of amplification attacks, given the source node will send notifications to delegated nodes who have not requested the resource directly. This negative effect can be controlled by several implementation considerations: a) the delegating node can negotiate with the delegated node before sending delegated observe, out of band; b) the source node will strictly control the rate of the notifications, so that flooding will be avoided; c) the delegated node can block any notifications beyond a certain data rate. 7 IANA Considerations If approved, an Option Number for the defined Delegated Observe Option for CoAP will be needed. Zhen Cao, et al. Expires [Page 6] INTERNET DRAFT draft-cao-core-delegated-observe | Number | Name | Reference | +--------+--------------------+-----------+ | TBD | Delegated Observe | [thisdoc] | 7 References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC7641] K. Hartke, "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, September 2015. Appendix A. Examples Source Delegate Target Node Node Node | | | | Delegated | | Header: GET 0x 86868686 |<-Observe-----| | Token: 0x55 | | | Uri-Path: temp | | | D-Observe: 10.0.0.2:5683 | | | | | | | | | Header: GET 0x 86868686 |--Notify(2.05)------------>| Token: 0x55 | | | D-Observe: 9 | | | Max-age: 15 | | | Payload: "18.8 Cel" | | | | | | Header: GET 0x 8686ab99 |--Notify(2.05)------------>| Token: 0x55 | | | D-Observe: 16 | | | Max-age: 15 | | | Payload: "19.2 Cel" Figure A.1: Example of Delegated Observe Authors' Addresses Zhen Cao, et al. Expires [Page 7] INTERNET DRAFT draft-cao-core-delegated-observe Zhen Cao Huawei Tech Beijing, China EMail: zhencao.ietf@gmail.com Rahul Arvind Jadhav Huawei Tech, Kundalahalli Village, Bangalore, India EMail: rahul.jadhav@huawei.com Zhen Cao, et al. Expires [Page 8]