idnits 2.17.1 draft-cao-core-delegated-observe-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2016) is 2736 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 218, but not defined == Unused Reference: 'RFC2119' is defined on line 270, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE WG Z. Cao 3 INTERNET-DRAFT R. Jadhav 4 Intended Status: Informational Huawei 5 Expires: April 26, 2016 6 October 27, 2016 8 CoAP Delegated Observe 9 draft-cao-core-delegated-observe-00 11 Abstract 13 This document discusses the scenarios for "delegated observe", in 14 which a subscriber needs to register some resources on behalf of some 15 other entities. This document also presents a CoAP protocol 16 extension for the delegated observe operation. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 INTERNET DRAFT draft-cao-core-delegated-observe 41 Copyright and License Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Scenarios for Delegated Observe . . . . . . . . . . . . . . . . 3 60 2.1 Multiple Devices . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2 Delegation to Cloud . . . . . . . . . . . . . . . . . . . . 3 62 2.3 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3 Overview of Delegated Observe . . . . . . . . . . . . . . . . . 4 64 4 The Delegated Observe Option . . . . . . . . . . . . . . . . . . 5 65 5 Handling Delegated Observe . . . . . . . . . . . . . . . . . . 6 66 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 72 INTERNET DRAFT draft-cao-core-delegated-observe 74 1 Introduction 76 CoAP [RFC7252] is a light-weight application protocol for constrained 77 networks. To avoid keeping polling devices, CoAP supports the 78 'observe' operation defined in [RFC7641], in which a subscriber can 79 register its interest to certain resources and then be updated with 80 their representation. However, in the current "observe" protocol, 81 the subscriber can only register interests on behalf of itself, and 82 therefore, updated information of the represented resources could not 83 be notified to any parties other than the one who sends the observe 84 request. 86 This document discusses the scenarios for "delegated observation", in 87 which a subscriber needs to register some resources on behalf of 88 other entities or a group of entities including itself. This 89 document also presents a CoAP protocol extension for the delegated 90 observe operation. 92 2 Scenarios for Delegated Observe 94 This section describes scenarios that needs delegated observe. 96 2.1 Multiple Devices 98 In a typical smart home network setup, a user with multiple devices 99 wants to observe some sensor resource (e.g., thermometer, bulbs). 100 Instead of sending CoAP Observe requests from every single device, 101 one of the them can send an Observe Registration on behalf of that 102 group of devices, so that all of them will be notified at once. 104 2.2 Delegation to Cloud 106 A user wants its mobile device to be notified of a certain sensor 107 information both in-home and off-home. When the device moves out of 108 its smart home network coverage, it is normally hidden behind NAT and 109 FW that keep it being reached for such notification messages. In 110 this case, the normal observe-notification scheme may fail. A walk- 111 around for this case is to let the device send a delegated observe 112 request while at home, asking the home sensors send notifications to 113 the device's representative cloud server, so that the device can 114 always fetch the information from it cloud service while off-home. 116 This scenario is depicted in Fig. 1. 118 INTERNET DRAFT draft-cao-core-delegated-observe 120 dev Cloud dev 121 Sensor in-home Server off-home 122 | | | | 123 | Delegated | | | 124 |<--Observe --| | | 125 | | | | 126 |--------Notification-------->| | 127 | | | 128 | |<-- GET--------| 129 | |----- ACK----->| 131 Figure 1: Delegation to Cloud 133 2.3 Multicast 135 A group of devices would like to observe the location information on a 136 motion sensor. This is a useful case when a number of light bulbs need 137 to adjust its lighting intensity based on the location of the observed 138 motion object. Instead of let each device register an interest on the 139 motion sensor, one of them could simply delegate the observe to this 140 multicast group, so that the location update notifications will be send 141 to the multicast address that they belong to. This scenario is 142 visualized in Fig.2. 144 Motion 145 Sensor Bulb_1 Bulb_2 Bulb_n 146 | | | | 147 | Delegated | | | 148 |<-Observe-----| | | 149 | | | | 150 | Multicast | | | 151 |--Notify ---->|----------->|----------->| 152 | | | | 153 | | | | 155 Figure 2: Delegation to a Multicast Group 157 3 Overview of Delegated Observe 159 As show in Fig.3, we name the node that has the direct representation of 160 the CoAP resource as the "Source node"; and the immediate node as the 161 'Delegate node' that will send delegated Observe request to the Source 162 node, on behalf of the "Delegated node" who will be notified by the 163 Source Node. 165 INTERNET DRAFT draft-cao-core-delegated-observe 167 Source Delegate Delegated 168 Node Node Node 169 | | | 170 | Delegated | | 171 |<-Observe-----| | 172 | | | 173 | | | 174 |--Notify ---->|----------->| 175 | | | 176 | | | 178 Figure 3: Overview of Delegated Observe 180 4 The Delegated Observe Option 182 The properties of the Delegated Observe Option are defined in Fig. 4. 184 In a GET request: 185 +-----+---+---+---+---+------------------+--------+--------+---------+ 186 | No. | C | U | N | R | Name | Format | Length | Default | 187 +-----+---+---+---+---+------------------+--------+--------+---------+ 188 | TBD | | x | - | | Delegated Observe| string | 0-256 | (none) | 189 +-----+---+---+---+---+------------------+--------+--------+---------+ 191 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 193 In a Response: 194 +-----+---+---+---+---+------------------+--------+--------+---------+ 195 | No. | C | U | N | R | Name | Format | Length | Default | 196 +-----+---+---+---+---+------------------+--------+--------+---------+ 197 | TBD | | x | - | | Delegated Observe| uint | 0-3 B | (none) | 198 +-----+---+---+---+---+------------------+--------+--------+---------+ 200 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 202 Figure 4: CoAP Delegated Observe Option 204 When included in a GET request, the Delegated Observe Option extends the 205 GET method so it does not only retrieve a current representation of the 206 target resource, but also requests the server to add an entry in the 207 list of observers of the resource. This entry maps the target resource 208 to an identifier of the observer contained in the value of this option. 210 When used to register the representation, the value of Delegated Observe 211 in a GET request is the identifier of the nodes that will be notified, 212 in the format of "IP:port" or "domain_name:port". 214 When used to de-register the representation, the value of Delegated 215 INTERNET DRAFT draft-cao-core-delegated-observe 217 Observe in the GET is a special string, e.g., in the format of ":::", 218 the specific format needs further discussion. [TBD] 220 When included in a response, the Delegated Observe Option identifies the 221 message as a notification. The Option value is used as a sequence number 222 used to infer the order of the notifications. The ordering inference is 223 the same as what has been discussed in Section 3.4 of [RFC7641]. 225 5 Handling Delegated Observe 227 Before sending the delegated observe, the "Delegate node" needs to know 228 which address:port on the Delegated node will be open to receive the 229 subsequent notification from the source node. This negotiation is out of 230 scope of this document. 232 Upon receiving the delegated observe request, the "Source Node" will 233 create an entry based on the identifier of the Delegated Node contained 234 within the request. The Source Node can decide if it needs to verify 235 the validity of the Delegated node, per its own policy. The validation 236 way is also out of the scope of this document. 238 The Delegated Node, once being delegated and verified by Source Node, 239 will be notified subsequently, although it does not send the request for 240 that resource. The Delegated Node interprets the CoAP message, and will 241 handle this message if the CoAP message contains a Delegated Observe 242 option defined in Section 4. 244 6 Security Considerations 246 The security considerations in [RFC7252] and [RFC7641] apply. 248 Delegated observe may increase the risk of amplification attacks, given 249 the source node will send notifications to delegated nodes who have not 250 requested the resource directly. This negative effect can be controlled 251 by several implementation considerations: a) the delegating node can 252 negotiate with the delegated node before sending delegated observe, out 253 of band; b) the source node will strictly control the rate of the 254 notifications, so that flooding will be avoided; c) the delegated node 255 can block any notifications beyond a certain data rate. 257 7 IANA Considerations 259 If approved, an Option Number for the defined Delegated Observe Option 260 for CoAP will be needed. 262 INTERNET DRAFT draft-cao-core-delegated-observe 264 | Number | Name | Reference | 265 +--------+--------------------+-----------+ 266 | TBD | Delegated Observe | [thisdoc] | 268 7 References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, DOI 272 10.17487/RFC2119, March 1997. 274 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "Constrained 275 Application Protocol (CoAP)", RFC 7252, June 2014. 277 [RFC7641] K. Hartke, "Observing Resources in the Constrained 278 Application Protocol (CoAP)", RFC 7641, September 2015. 280 Appendix A. Examples 282 Source Delegate Target 283 Node Node Node 284 | | | 285 | Delegated | | Header: GET 0x 86868686 286 |<-Observe-----| | Token: 0x55 287 | | | Uri-Path: temp 288 | | | D-Observe: 10.0.0.2:5683 289 | | | 290 | | | 291 | | | Header: GET 0x 86868686 292 |--Notify(2.05)------------>| Token: 0x55 293 | | | D-Observe: 9 294 | | | Max-age: 15 295 | | | Payload: "18.8 Cel" 296 | | | 297 | | | Header: GET 0x 8686ab99 298 |--Notify(2.05)------------>| Token: 0x55 299 | | | D-Observe: 16 300 | | | Max-age: 15 301 | | | Payload: "19.2 Cel" 302 Figure A.1: Example of Delegated Observe 304 Authors' Addresses 305 INTERNET DRAFT draft-cao-core-delegated-observe 307 Zhen Cao 308 Huawei Tech 309 Beijing, China 311 EMail: zhencao.ietf@gmail.com 313 Rahul Arvind Jadhav 314 Huawei Tech, 315 Kundalahalli Village, 316 Bangalore, India 318 EMail: rahul.jadhav@huawei.com