idnits 2.17.1 draft-jimenez-p2psip-coap-reload-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 519 has weird spacing: '...sorInfo senso...' == Line 542 has weird spacing: '...sorInfo senso...' -- The document date (June 9, 2015) is 3243 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-02 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP J. Jimenez 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Lopez-Vega 5 Expires: December 11, 2015 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 June 9, 2015 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-09 15 Abstract 17 This document defines a Constrained Application Protocol (CoAP) Usage 18 for REsource LOcation And Discovery (RELOAD). The CoAP Usage 19 provides the functionality to federate Wireless Sensor Networks (WSN) 20 in a peer-to-peer fashion. The CoAP Usage for RELOAD allows CoAP 21 nodes to store resources in a RELOAD peer-to-peer overlay, provides a 22 lookup service, and enables the use of RELOAD overlay as a cache for 23 sensor data. This functionality is implemented in the RELOAD overlay 24 itself, without the use of centralized servers. The RELOAD AppAttach 25 method is used to establish a direct connection between nodes through 26 which CoAP messages are exchanged. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 11, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 7 66 5. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Forming a Direct Connection and Reading Data . . . . . . . . 9 68 7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 12 71 8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 14 72 8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . 14 73 8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 14 74 9. Access Control Rules . . . . . . . . . . . . . . . . . . . . 15 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 11.1. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . 16 78 11.2. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . 16 79 11.3. Access Control Policies . . . . . . . . . . . . . . . . 17 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The CoAP Usage for RELOAD allows CoAP nodes to store resources in a 88 RELOAD peer-to-peer overlay, provides a lookup service, and enables 89 the use of RELOAD overlay as a cache for sensor data. This 90 functionality is implemented in the RELOAD overlay itself, without 91 the use of centralized servers. 93 This usage is intended for interconnected devices over a wide-area 94 geographical coverage. For example in cases where multiple Wireless 95 Sensor Networks (WSN) need to be federated over some wider-area 96 network. These WSNs would interconnect by means of nodes that are 97 equipped with long range modules (e.g., 2G, 3G, 4G) as well as short 98 range ones (e.g., XBee, ZigBee, BLE). 100 Constrained devices are likely to be heterogeneous when it comes to 101 their radio layer, however we expect them to use a common application 102 layer protocol, CoAP. The Constrained Application Protocol (CoAP) is 103 a specialized web transfer protocol [RFC7252]. It realizes the 104 Representational State Transfer (REST) architecture for the most 105 constrained nodes, such as sensors and actuators. CoAP can be used 106 not only between nodes on the same constrained network but also 107 between constrained nodes and nodes on the Internet. The latter is 108 possible since CoAP can be translated to Hypertext Transfer Protocol 109 (HTTP) for integration with the web. Application areas of CoAP 110 include different forms of M2M communication, such as home 111 automation, construction, health care or transportation. Areas with 112 heavy use of sensor and actuator devices that monitor and interact 113 with the surrounding environment. 115 As specified in [RFC6940] RELOAD is fundamentally an overlay network. 116 Providing a layered architecture with pluggable application layers 117 than can use the underlaying forwarding, storage and lookup 118 functionalities. Figure 1 illustrates where the CoAP Usage is placed 119 within the RELOAD architecture. 121 Application 123 +-------+ 124 | CoAP | ... 125 | Usage | 126 +-------+ 127 ------------------------------------ Messaging Service 128 +------------------+ +---------+ 129 | Message |<--->| Storage | 130 | Transport | +---------+ 131 +------------------+ ^ 132 ^ ^ | 133 | v v 134 | +-------------------+ 135 | | Topology | 136 | | Plug-in | 137 | +-------------------+ 138 | ^ 139 v v 140 +------------------+ 141 | Forwarding & | 142 | Link Management | 143 +------------------+ 144 ------------------------------------ Overlay Link Service 145 +-------+ +-------+ 146 |TLS | |DTLS | ... 147 |Overlay| |Overlay| 148 |Link | |Link | 149 +-------+ +-------+ 151 Figure 1: Architecture 153 The CoAP Usage involves three basic functions: 155 Registration: CoAP nodes that can use the RELOAD data storage 156 functionality, can store a mapping from their CoAP URI to their Node- 157 ID in the overlay. They can also retrieve the Node-IDs of other 158 nodes. Nodes that are not RELOAD aware can use other mechanisms, for 159 example [I-D.ietf-core-resource-directory] in their local network. 161 Lookup: Once a CoAP node has identified the Node-ID for an URI it 162 wishes to retrieve, it can use the RELOAD message routing system to 163 set up a connection which can be used to exchange CoAP messages. 164 Similarly as with the registration, nodes that are not RELOAD aware 165 can use CoAP messages with an Reload Node (RN) that will in turn 166 perform the lookup in the overlay. 168 Caching: Nodes can use the RELOAD overlay as a caching mechanism for 169 information about what CoAP resources are available on the node. 170 This is specially useful for battery constrained nodes that can make 171 their data available in the cache provided by the overlay while in 172 sleep mode. 174 For instance, a CoAP proxy (See Section 3) could register its Node-ID 175 (e.g. "9996172") and a list of sensors (e.g. "/sensors/temp-1; 176 /sensors/temp-2; /sensors/light, /sensors/humidity") under its URI 177 (e.g. "coap://overlay-1.com/proxy-1/"). 179 When a node wants to discover the values associated with that URI, it 180 queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back 181 the Node-ID of the proxy and the list of its associated sensors. The 182 requesting node can then use the RELOAD overlay to establish a direct 183 connection with the proxy and to read sensor values. 185 Moreover, the CoAP proxy can store the sensor information in the 186 overlay. In this way information can be retrieved directly from the 187 overlay without performing a direct connection to the storing proxy. 189 2. Terminology 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in RFC 2119 [RFC2119]. 195 We use the terminology and definitions from the RELOAD Base Protocol 196 [RFC6940] extensively in this document. Some of those concepts are 197 further described in the Concepts and Terminology for Peer to Peer 198 SIP [I-D.ietf-p2psip-concepts] document. 200 3. Architecture 202 In our architecture we extend the different nodes present in RELOAD 203 (Peer, Client) and add support for sensor devices or other 204 constrained devices. Figure 2 illustrates the overlay topology. The 205 different nodes, according to their functionality are : 207 Client 208 Devices that are capable of participating in a RELOAD overlay as 209 client nodes, that is they do not route messages in the overlay. 211 Router 212 Devices that are members of (i.e., peers in) a RELOAD overlay and 213 capable of forwarding RELOAD messages following a path through the 214 overlay to the destination. 216 Sensor 217 Devices capable of measuring a physical quantity. Sensors usually 218 acquire quantifiable information about their surrounding 219 environment such as: temperature, humidity, electric current, 220 moisture, radiation, and so on. 222 Actuator 223 Devices capable of interacting and affecting their environment 224 such as: electrical motors, pneumatic actuators, electric 225 switches, and so on. 227 Proxy 228 Devices having sufficient resources to run RELOAD either as client 229 or peer. These devices are located at the edge of the sensor 230 network and, in case of Wireless Sensor Networks (WSN), act as 231 coordinators of the network. 233 Physical devices can have one or several of the previous functional 234 roles. According to the functionalities that are present in each of 235 the nodes, they can be: 237 Constrained Node 238 A Constrained Node (CN) is a node with limited computational 239 capabilities. CN devices belong to classes of at least C1 and C2 240 devices as defined in [RFC7228], their main constraint being the 241 implementation of the CoAP protocol. If the CN is wireless then 242 it will be part of a Low-Rate Wireless Personal Area Network (LR- 243 WPAN), also termed Low-Power and Lossy Network (LLN). Lastly, 244 devices will usually be in sleep mode in order to prevent battery 245 drain, and will not communicate during those periods. A CN is NOT 246 part of the RELOAD overlay, therefore it can not act as a client, 247 router nor proxy. A CN is always either a either a Sensor or an 248 Actuator. In the latter case the node is often connected to a 249 continuous energy power supply. 251 RELOAD Node 252 A Reload Node (RN) MUST implement the client functionality in the 253 Overlay. Additionally the node will often be a full RELOAD peer. 254 A RN may also be sensor or actuator since it can have those 255 devices connected to it. 257 Proxy Node 258 A Proxy Node (PN) MUST implement the RN functionality and act as a 259 sink for the LR-WPAN network. The PN connects the short range 260 Wireless Network to the Wide Area Network or the Internet. A 261 Proxy Node fulfills the "Proxy" role as described above. 263 +------+ 264 | | 265 +--------+ RN +---------+ 266 | | | | 267 +---+--+ +------+ +--+---+ 268 | | | | 269 | RN | | RN | 270 | | | | +------------+ 271 +---+--+ +--+---+ | WSN | 272 | RELOAD | | +----+ | 273 | OVERLAY | | +---+ CN | | 274 +---+--+ +--+---+ | | +----+ | 275 | | | +-----+ | 276 | RN | | PN | | | 277 | | | +-----+ | 278 +---+--+ +------+ +--+---+ | | +----+ | 279 | | | | | +---+ CN | | 280 +--------+ PN +---------+ | +----+ | 281 | | +------------+ 282 +-+--+-+ 283 | | 284 +--------|--|--------+ 285 | +--+ +--+ | 286 | | | | 287 | +--+-+ +-+--+ | 288 | | CN | | CN | | 289 | +----+ +----+ | 290 | WSN | 291 +--------------------+ 293 Figure 2: Overlay Topology 295 4. Registering CoAP URIs 297 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 298 a RELOAD environment, URI resolution is provided by the overlay as a 299 whole. Instead of registering a URI, a peer stores a 300 CoAPRegistration structure under a hash of its own URI. This uses 301 the CoAP REGISTRATION Kind-ID, which is formally defined in 302 Section 6, and that uses a DICTIONARY data model. 304 As an example, if a CoAP proxy that is located in an overlay overlay- 305 1.com using a Node-ID "9996172" wants to register four different 306 sensors to the URI "coap://overlay-1.com/proxy-1/.well-known/". We 307 will be using the link format specified in [RFC6690] to store the 308 following mapping in the overlay: 310 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 311 KEY = 9996172, 313 VALUE = [ 314 ;rt="temperature-c";if="sensor", 315 ;rt="temperature-c";if="sensor", 316 ;rt="light-lux";if="sensor", 317 ;rt="humidity-p";if="sensor" 318 ] 320 Note that the Resource-ID stored in the overlay is calculated as hash 321 over the URI (i.e. h(URI)), which in RELOAD usually is SHA-1. 323 This would inform any other node performing a lookup for the previous 324 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 325 for proxy-1 is "9996172". In addition, this mapping provides 326 relevant information as to the number of sensors (CNs) and the URI 327 path to connect to them using CoAP. 329 5. Lookup 331 The RELOAD overlay supports a rendezvous system that can be used for 332 the lookup of other CoAP nodes. This is done by fetching mapping 333 information between CoAP URIs and Node-IDs. 335 As an example, if a node RN located in the overlay overlay-1.com 336 wishes to read which resources are served at a RN with URI 337 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 338 The Resource-ID used in this fetch is a SHA-1 hash over the URI 339 "coap://overlay-1.com/proxy-1/.well-known/". 341 After this fetch request, the overlay will return the following 342 result: 344 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 345 KEY = 9996172, 347 VALUE = [ 348 ;rt="temperature-c";if="sensor", 349 ;rt="temperature-c";if="sensor", 350 ;rt="light-lux";if="sensor", 351 ;rt="humidity-p";if="sensor" 352 ] 354 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 355 VALUE pair. The VALUE is the set of URIs necessary to read data from 356 the CNs associated with the RN. 358 Using the RELOAD DICTIONARY model allows for multiple nodes to 359 perform a store to the same Resource-ID. This can be used, for 360 example, to perform a store of resources of the same type or with 361 similar characteristics. After performing a lookup, this feature 362 allows to fetch those multiple RNs that host CNs of the same class. 364 As an example, providing that the previous peer (9996172) and another 365 peer (9996173) have stored the links to their respective temperature 366 resources in this same Resource-ID (temperature), a RN (e.g., node-A) 367 can do a fetch to the URI "coap://overlay-1.com/temperature/.well- 368 known/", obtaining the following results: 370 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 372 KEY = 9996172, 373 VALUE = [ 374 ;rt="temperature-c";if="sensor", 375 ;rt="temperature-c";if="sensor", 376 ] 378 KEY = 9996173, 379 VALUE = [ 380 ;rt="temperature-c";if="sensor", 381 ;rt="temperature-c";if="sensor" 382 ] 384 6. Forming a Direct Connection and Reading Data 386 Once a RN (e.g., node-A) has obtained the lookup information for a 387 node in the overlay (e.g., proxy-1), it can directly connect to that 388 node. This is performed by sending an AppAttach request to the Node- 389 ID obtained during the lookup process. 391 After the AppAttach negotiation, node-A can access to the values of 392 the CNs at proxy-1 using the information obtained during the lookup. 393 Following the example in Section 5, and according to [RFC6690], the 394 requests for accessing to the CNs at proxy-1 would be: 396 REQ: GET /sensors/temp-1 397 REQ: GET /sensors/temp-2 399 Figure 3 shows a sample of a node reading temperature data. 401 +-----+ +---------+ +-----+ +---+ 402 | PNA | | OVERLAY | | PNB | |CNB| 403 +-----+ +---------+ +-----+ +---+ 404 | | | | 405 | | | | 406 | 1.RELOAD | | | 407 | FetchReq | | | 408 |+----------->| | | 409 | | | | 410 | 2.RELOAD | | | 411 | FetchAns | | | 412 |<-----------+| | | 413 | | | | 414 | 3.RELOAD | | | 415 | AppAttach | | | 416 |+----------->| | | 417 | | 4.RELOAD | | 418 | | AppAttach | | 419 | |+---------->| | 420 | | | | 421 | | 5.RELOAD | | 422 | 6.RELOAD |AppAttachAns| | 423 |AppAttachAns |<----------+| | 424 |<-----------+| | | 425 | | | | 426 | | | 427 | --------------------- | | 428 | / 7.ICE \| | 429 | \ connectivity checks /| | 430 | --------------------- | | 431 | | | 432 | 8.CoAP CON | | 433 | GET /sensors/temp-1 | | 434 |+------------------------>| | 435 | | 9.CoAP GET | 436 | |/sensors/temp-1 | 437 | |+-------------->| 438 | | 10.CoAP | 439 | 11.CoAP | ACK 200 | 440 | ACK 200 |<--------------+| 441 |<------------------------+| | 442 | | | 444 Figure 3: An Example of a Message Sequence 446 7. Caching Mechanisms 448 The CoAP protocol itself supports the caching of sensor information 449 in order to reduce the response time and network bandwidth 450 consumption of future, equivalent requests. CoAP caching is 451 specified in the Section 5 of the CoAP RFC [RFC7228], it consists on 452 reusing stored responses when new requests arrives. This type of 453 storage is done in CoAP proxies. 455 This CoAP usage for RELOAD proposes an additional caching mechanism 456 for storing sensor information directly in the overlay. In order to 457 do so, it is necessary to define how the data should be stored. Such 458 caching mechanism is primarily intended for CNs with sensor 459 capabilities, not for RN sensors. This is due to the battery 460 constrains of CNs, forcing them to stay in sleep mode for long 461 periods of time. 463 Whenever a CN wakes up, it sends the most recent data from its 464 sensors to its proxy (PN), which stores the data in the overlay using 465 a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC 466 [RFC6940]. We use the StoredDataValue structure defined in 467 Section 6.2 of the RELOAD RFC, in particular we use the SingleValue 468 format type to store the cached values in the overlay. From that 469 structure length, storage_time, lifetime and Signature are used in 470 the same way. The only difference is DataValue which in our case can 471 be either a ProxyCache or a SensorCache: 473 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 474 CoAPCachingType; 475 struct { 476 CoAPCachingType coap_caching_type; 478 select(coap_caching_type) { 479 case proxy_cache: ProxyCache proxy_cache_entry; 480 case sensor_cache: SensorCache sensor_cache_entry; 481 /* extensions */ 483 } 484 } CoAPCaching; 486 7.1. ProxyCache 488 ProxyCache is meant to store values and sensor information (e.g. 489 inactivity time) for all the sensors associated with a certain proxy, 490 as well as their CoAP URIs. On the other hand, SensorCache is used 491 for storing the information and cached value of only one sensor (CoAP 492 URI is not necessary, as is the same as the one used for generating 493 the Resource-ID associated to that SensorCache entry). 495 ProxyCache contains the fields Node-ID and series of SensorEntry 496 types. 498 struct { 499 Node-ID Node_ID; 500 uint32 length; 501 SensorEntry sensors[count]; 502 } ProxyCache; 504 Node-D 505 The Node-ID of the Proxy Node (PN) responsible for different 506 sensor devices; 508 length 509 The length of the rest of the structure; 511 Sensor-Entry 512 List of sensors in the form of SensorEntry types; 514 SensorEntry contains the coap_uri, sensor_info and a series of 515 SensorValue types. 517 struct { 518 opaque coap_uri; 519 SensorInfo sensor_info; 520 uint32 length; 521 SensorValue sensor_value[count]; 522 } SensorEntry; 524 coap_uri 525 CoAP name of the sensor device in question; 527 sensor_info 528 contains relevant sensor information; 530 length 531 The length of the rest of the structure; 533 sensor_value 534 contains a list of values stored by the sensor; 536 7.2. SensorCache 538 SensorCache: contains the information related to one sensor. 540 struct { 541 Node-ID Node_ID; 542 SensorInfo sensor_info; 543 uint32 length; 544 SensorValue sensor_value[count]; 545 } SensorCache; 547 Node_ID 548 identifies the Node-ID of the Proxy Node responsible for the 549 sensor; 551 sensor_info 552 contains relevant sensor information; 554 length 555 The length of the rest of the structure; 557 sensor_value 558 contains a list of values stored by the sensor; 560 SensorInfo contains relevant sensor information that is dependent on 561 the use case. As an example we use the sensor manufacturer as 562 relevant information. 564 struct { 565 opaque dev_info; 567 /* extensions */ 569 } SensorInfo; 571 dev_info 572 Contains specific device information as defined in [RFC6690], for 573 example temperature, luminosity, etc. It can also represent other 574 semantic information about the device. 576 SensorValue contains the measurement_time, lifetime and value of the 577 measurement. 579 struct { 580 uint32 measurement_time; 581 uint32 lifetime; 582 opaque value; 584 /* extensions */ 586 } SensorValue; 587 measurement_time 588 indicates the moment in which the measure was taken represented as 589 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 590 not counting leap seconds; 592 lifetime 593 indicates the validity time of that measured value in milliseconds 594 since measurement_time; 596 value 597 indicates the actual value measured. It can be of different types 598 (integer, long, string) therefore opaque has been used; 600 8. CoAP Usage Kinds Definition 602 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 604 8.1. CoAP-REGISTRATION Kind 606 Kind IDs 607 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 608 URI. The data stored is a CoAPRegistration, which contains a set 609 of CoAP URIs. 611 Data Model 612 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 613 The dictionary key is the Node-ID of the storing RN. This allows 614 each RN to store a single mapping. 616 Access Control 617 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 618 COAP URI before matching. 620 Data stored under the COAP-REGISTRATION kind is of type 621 CoAPRegistration, defined below. 623 struct { 624 Node-ID Node_ID; 625 uint16 coap_uris_length; 626 opaque coap_uris (0..2^16-1); 627 } CoAPRegistration; 629 8.2. CoAP-CACHING Kind 631 KindIDs 632 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 633 The data stored is a CoAPCaching, which contains a cached value. 635 Data Model 636 The data model for the CoAP-CACHING Kind-ID is single value. 638 Access Control 639 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 640 URI before matching. 642 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 643 defined in Section 7. 645 9. Access Control Rules 647 As specified in RELOAD base [RFC6940], every kind which is storable 648 in an overlay must be associated with an access control policy. This 649 policy defines whether a request from a given node to operate on a 650 given value should succeed or fail. Usages can define any access 651 control rules they choose, including publicly writable values. 653 CoAP Usage for RELOAD requires an access control policy that allows 654 multiple nodes in the overlay read and write access. This access is 655 for registering and caching information using CoAP URIs as 656 identifiers. Therefore, none of the access control policies 657 specified in RELOAD base are sufficient . 659 This document defines two access control policies , called URI-MATCH 660 and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be 661 written and overwritten if and only if the signer's certificate has 662 an associated URI which canonicalized form hashes (using the hash 663 function for the overlay) to the Resource-ID for the resource. The 664 certificate can be calculated as specified on Section 9, certificate 665 option of the CoAP [RFC7228] specification. 667 In URI-NODE-MATCH policy, a given value MUST be written and 668 overwritten if and only if the condition for URI-MATCH is met and, in 669 addition, the dictionary key is equal to the Node-ID in the 670 certificate and that Node-ID is the one indicated in the 671 SignerIdentity value cert_hash. 673 These Access Control Policies are specified for IANA in 674 Section Section 11.3. 676 10. Security Considerations 678 The security considerations of RELOAD [RFC6940] and CoAP [RFC7228] 679 apply to this specification. RELOAD's security model is based on 680 public key certificates, which are used for signing messages and 681 stored objects. At the connection level RELOAD can use either TLS or 682 DTLS. In the case of CoAP, several security modes have been defined. 684 Implementations of this specification MUST follow all the security- 685 related rules specified in the RELOAD [RFC6940] and CoAP [RFC7228] 686 specifications. 688 Additionally, in RELOAD every kind which is storable in an overlay 689 must be associated with an access control policy. This document 690 specifies two new access control policies, which are specified in 691 Section Section 9. These policies cover the most typical deployment 692 scenarios. 694 During the phase of registration and lookup, security considerations 695 relevant to RELOAD apply. The caching mechanism specified in this 696 draft is additional to the caching already done in CoAP. Access 697 control is handled by the RELOAD overlay, where the peer storing the 698 data is responsible of validating the signature on the data being 699 stored. 701 11. IANA Considerations 703 11.1. CoAP-REGISTRATION Kind-ID 705 This document introduces one additional data Kind-ID to the "RELOAD 706 Data Kind-ID" Registry: 708 +-------------------+------------+----------+ 709 | Kind | Kind-ID | RFC | 710 +-------------------+------------+----------+ 711 | CoAP-REGISTRATION | 105 | RFC-AAAA | 712 +-------------------+------------+----------+ 714 This Kind-ID was defined in Section 4. 716 11.2. CoAP-CACHING Kind-ID 718 This document introduces one additional data Kind-ID to the "RELOAD 719 Data Kind-ID" Registry: 721 +--------------+------------+----------+ 722 | Kind | Kind-ID | RFC | 723 +--------------+------------+----------+ 724 | CoAP-CACHING | 106 | RFC-AAAA | 725 +--------------+------------+----------+ 727 This Kind-ID was defined in Section 4. 729 11.3. Access Control Policies 731 IANA is asked to create a "CoAP Usage for RELOAD Access Control 732 Policy" Registry. Entries in this registry are strings denoting 733 access control policies, as described in Section 8.1. New entries in 734 this registry are to be registered per the Specification Required 735 policy in [RFC5226]. The initial contents of this registry are: 737 +-----------------+----------+ 738 | Access Policy | RFC | 739 +-----------------+----------+ 740 | URI-NODE-MATCH | RFC-AAAA | 741 | URI-MATCH | RFC-AAAA | 742 +-----------------+----------+ 744 This access control policy was described in Section 9. 746 12. References 748 12.1. Normative References 750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 751 Requirement Levels", BCP 14, RFC 2119, March 1997. 753 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 754 Format", RFC 6690, August 2012. 756 [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 757 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 758 Base Protocol", RFC 6940, January 2014. 760 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 761 Application Protocol (CoAP)", RFC 7252, June 2014. 763 12.2. Informative References 765 [I-D.ietf-core-resource-directory] 766 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 767 draft-ietf-core-resource-directory-02 (work in progress), 768 November 2014. 770 [I-D.ietf-p2psip-concepts] 771 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 772 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 773 draft-ietf-p2psip-concepts-06 (work in progress), June 774 2014. 776 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 777 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 778 May 2008. 780 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 781 Constrained-Node Networks", RFC 7228, May 2014. 783 Authors' Addresses 785 Jaime Jimenez 786 Ericsson 787 Hirsalantie 11 788 Jorvas 02420 789 Finland 791 Email: jaime.jimenez@ericsson.com 793 Jose M. Lopez-Vega 794 University of Granada 795 CITIC UGR Periodista Rafael Gomez Montero 2 796 Granada 18071 797 Spain 799 Email: jmlvega@ugr.es 801 Jouni Maenpaa 802 Ericsson 803 Hirsalantie 11 804 Jorvas 02420 805 Finland 807 Email: jouni.maenpaa@ericsson.com 809 Gonzalo Camarillo 810 Ericsson 811 Hirsalantie 11 812 Jorvas 02420 813 Finland 815 Email: gonzalo.camarillo@ericsson.com