idnits 2.17.1 draft-jimenez-p2psip-coap-reload-08.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 513 has weird spacing: '...sorInfo senso...' == Line 536 has weird spacing: '...sorInfo senso...' -- The document date (April 15, 2015) is 3299 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: October 17, 2015 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 April 15, 2015 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-08 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 October 17, 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 . . . . . . . . . . . . . . . . . . . . 15 74 9. Access Control Rules . . . . . . . . . . . . . . . . . . . . 15 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 11.1. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . 16 78 11.2. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . 17 79 11.3. Access Control Policies . . . . . . . . . . . . . . . . 17 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 This usage is intended for interconnected devices over a wide-area 88 geographical coverage. For example in cases multiple Wireless Sensor 89 Networks (WSN) that need to be federated over some wider-area 90 network. These would interconnect by means of nodes that are 91 equipped with long range modules (e.g., 2G, 3G, 4G) as well as short 92 range ones (e.g., XBee, ZigBee, BLE). 94 Constrained devices are likely to be heterogeneous when it comes to 95 their radio layer, however we expect them to use a common application 96 layer protocol, CoAP. The Constrained Application Protocol (CoAP) is 97 a specialized web transfer protocol [RFC7252]. It realizes the 98 Representational State Transfer (REST) architecture for the most 99 constrained nodes, such as sensors and actuators. CoAP can be used 100 not only between nodes on the same constrained network but also 101 between constrained nodes and nodes on the Internet. The latter is 102 possible since CoAP can be translated to Hypertext Transfer Protocol 103 (HTTP) for integration with the web. Application areas of CoAP 104 include different forms of M2M communication, such as home 105 automation, construction, health care or transportation. Areas with 106 heavy use of sensor and actuator devices that monitor and interact 107 with the surrounding environment. 109 As specified in [RFC6940] RELOAD is fundamentally an overlay network. 110 Providing a layered architecture with pluggable application layers 111 than can use the underlaying forwarding, storage and lookup 112 functionalities. Figure 1 illustrates where the CoAP Usage is placed 113 within the RELOAD architecture. 115 Application 117 +-------+ 118 | CoAP | ... 119 | Usage | 120 +-------+ 121 ------------------------------------ Messaging Service 122 +------------------+ +---------+ 123 | Message |<--->| Storage | 124 | Transport | +---------+ 125 +------------------+ ^ 126 ^ ^ | 127 | v v 128 | +-------------------+ 129 | | Topology | 130 | | Plug-in | 131 | +-------------------+ 132 | ^ 133 v v 134 +------------------+ 135 | Forwarding & | 136 | Link Management | 137 +------------------+ 138 ------------------------------------ Overlay Link Service 139 +-------+ +-------+ 140 |TLS | |DTLS | ... 141 |Overlay| |Overlay| 142 |Link | |Link | 143 +-------+ +-------+ 145 Figure 1: Architecture 147 The CoAP Usage involves three basic functions: 149 Registration: CoAP nodes that can use the RELOAD data storage 150 functionality, can store a mapping from their CoAP URI to their Node- 151 ID in the overlay. They can also retrieve the Node-IDs of other 152 nodes. Nodes that are not RELOAD aware can use other mechanisms, for 153 example [I-D.ietf-core-resource-directory] in their local network. 155 Lookup: Once a CoAP node has identified the Node-ID for an URI it 156 wishes to retrieve, it can use the RELOAD message routing system to 157 set up a connection which can be used to exchange CoAP messages. 158 Similarly as with the registration, nodes that are not RELOAD aware 159 can use CoAP messages with an RN that will in turn perform the lookup 160 in the overlay. 162 Caching: Nodes can use the RELOAD overlay as a caching mechanism for 163 information about what CoAP resources are available on the node. 164 This is specially useful for battery constrained nodes that can make 165 their data available in the cache provided by the overlay while in 166 sleep mode. 168 For instance, a CoAP proxy (See Section 3) could register its Node-ID 169 (e.g. "9996172") and a list of sensors (e.g. "/sensors/temp-1; 170 /sensors/temp-2; /sensors/light, /sensors/humidity") under its URI 171 (e.g. "coap://overlay-1.com/proxy-1/"). 173 When a node wants to discover the values associated with that URI, it 174 queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back 175 the Node-ID of the proxy and the list of its associated sensors. The 176 requesting node can then use the RELOAD overlay to establish a direct 177 connection with the proxy and to read sensor values. 179 Moreover, the CoAP proxy can store the sensor information in the 180 overlay. In this way information can be retrieved directly from the 181 overlay without performing a direct connection to the storing proxy. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119 [RFC2119]. 189 We use the terminology and definitions from the RELOAD Base Protocol 190 [RFC6940] extensively in this document. Some of those concepts are 191 further described in the Concepts and Terminology for Peer to Peer 192 SIP [I-D.ietf-p2psip-concepts] document. 194 3. Architecture 196 In our architecture we extend the different nodes present in RELOAD 197 (Peer, Client) and add support for sensor devices or other 198 constrained devices. Figure 2 illustrates our architecture. The 199 different nodes, according to their functionality are : 201 Client 202 Devices that are capable of participating in a RELOAD overlay as 203 client nodes, that is they do not route messages in the overlay. 205 Router 206 Devices that are members of (i.e., peers in) a RELOAD overlay and 207 capable of forwarding RELOAD messages following a path through the 208 overlay to the destination. 210 Sensor 211 Devices capable of measuring a physical quantity. Sensors usually 212 acquire quantifiable information about their surrounding 213 environment such as: temperature, humidity, electric current, 214 moisture, radiation, and so on. 216 Actuator 217 Devices capable of interacting and affecting their environment 218 such as: electrical motors, pneumatic actuators, electric 219 switches, and so on. 221 Proxy 222 Devices having sufficient resources to run RELOAD either as client 223 or peer. These devices are located at the edge of the sensor 224 network and, in case of Wireless Sensor Networks (WSN), act as 225 coordinators of the network. 227 Physical devices can have one or several of the previous functional 228 roles. According to the functionalities that are present in each of 229 the nodes, they can be: 231 Constrained Node 232 A Constrained Node (CN) is a node with limited computational 233 capabilities. CN devices belong to classes of at least C1 and C2 234 devices as defined in [RFC7228], their main constraint being the 235 implementation of the CoAP protocol. If the CN is wireless then 236 it will be part of a Low-Rate Wireless Personal Area Network (LR- 237 WPAN), also termed Low-Power and Lossy Network (LLN). Lastly, 238 devices will usually be in sleep mode in order to prevent battery 239 drain, and will not communicate during those periods. A CN is NOT 240 part of the RELOAD overlay, therefore it can not act as a client, 241 router nor proxy. A CN is always either a either a Sensor or an 242 Actuator. In the latter case the node is often connected to a 243 continuous energy power supply. 245 RELOAD Node 246 A Reload Node (RN) MUST implement the client functionality in the 247 Overlay. Additionally the node will often be a full RELOAD peer. 248 A RN may also be sensor or actuator since it can have those 249 devices connected to it. 251 Proxy Node 252 A Proxy Node (PN) MUST implement the RN functionality and act as a 253 sink for the LR-WPAN network. The PN connects the short range 254 Wireless Network to the Wide Area Network or the Internet. A 255 Proxy Node fulfills the "Proxy" role as described above. 257 +------+ 258 | | 259 +--------+ RN +---------+ 260 | | | | 261 +---+--+ +------+ +--+---+ 262 | | | | 263 | RN | | RN | 264 | | | | +------------+ 265 +---+--+ +--+---+ | WSN | 266 | RELOAD | | +----+ | 267 | OVERLAY | | +---+ CN | | 268 +---+--+ +--+---+ | | +----+ | 269 | | | +-----+ | 270 | RN | | PN | | | 271 | | | +-----+ | 272 +---+--+ +------+ +--+---+ | | +----+ | 273 | | | | | +---+ CN | | 274 +--------+ PN +---------+ | +----+ | 275 | | +------------+ 276 +-+--+-+ 277 | | 278 +--------|--|--------+ 279 | +--+ +--+ | 280 | | | | 281 | +--+-+ +-+--+ | 282 | | CN | | CN | | 283 | +----+ +----+ | 284 | WSN | 285 +--------------------+ 287 Figure 2: Overlay Topology 289 4. Registering CoAP URIs 291 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 292 a RELOAD environment, URI resolution is provided by the overlay as a 293 whole. Instead of registering a URI, a peer stores a 294 CoAPRegistration structure under a hash of its own URI. This uses 295 the CoAP REGISTRATION Kind-ID, which is formally defined in 296 Section 6, and that uses a DICTIONARY data model. 298 As an example, if a CoAP proxy that is located in an overlay overlay- 299 1.com using a Node-ID "9996172" wants to register four different 300 sensors to the URI "coap://overlay-1.com/proxy-1/.well-known/". We 301 will be using the link format specified in [RFC6690] to store the 302 following mapping in the overlay: 304 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 305 KEY = 9996172, 307 VALUE = [ 308 ;rt="temperature-c";if="sensor", 309 ;rt="temperature-c";if="sensor", 310 ;rt="light-lux";if="sensor", 311 ;rt="humidity-p";if="sensor" 312 ] 314 Note that the Resource-ID stored in the overlay is calculated as hash 315 over the URI (i.e. h(URI)), which in RELOAD usually is SHA-1. 317 This would inform any other node performing a lookup for the previous 318 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 319 for proxy-1 is "9996172". In addition, this mapping provides 320 relevant information as to the number of sensors (CNs) and the URI 321 path to connect to them using CoAP. 323 5. Lookup 325 The RELOAD overlay supports a rendezvous system that can be used for 326 the lookup of other CoAP nodes. This is done by fetching mapping 327 information between CoAP URIs and Node-IDs. 329 As an example, if a node RN located in the overlay overlay-1.com 330 wishes to read which resources are served at a RN with URI 331 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 332 The Resource-ID used in this fetch is a SHA-1 hash over the URI 333 "coap://overlay-1.com/proxy-1/.well-known/". 335 After this fetch request, the overlay will return the following 336 result: 338 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 339 KEY = 9996172, 341 VALUE = [ 342 ;rt="temperature-c";if="sensor", 343 ;rt="temperature-c";if="sensor", 344 ;rt="light-lux";if="sensor", 345 ;rt="humidity-p";if="sensor" 346 ] 348 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 349 VALUE pair. The VALUE is the set of URIs necessary to read data from 350 the CNs associated with the RN. 352 Using the RELOAD DICTIONARY model allows for multiple nodes to 353 perform a store to the same Resource-ID. This can be used, for 354 example, to perform a store of resources of the same type or with 355 similar characteristics. After performing a lookup, this feature 356 allows to fetch those multiple RNs that host CNs of the same class. 358 As an example, providing that the previous peer (9996172) and another 359 peer (9996173) have stored the links to their respective temperature 360 resources in this same Resource-ID (temperature), a RN (e.g., node-A) 361 can do a fetch to the URI "coap://overlay-1.com/temperature/.well- 362 known/", obtaining the following results: 364 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 366 KEY = 9996172, 367 VALUE = [ 368 ;rt="temperature-c";if="sensor", 369 ;rt="temperature-c";if="sensor", 370 ] 372 KEY = 9996173, 373 VALUE = [ 374 ;rt="temperature-c";if="sensor", 375 ;rt="temperature-c";if="sensor" 376 ] 378 6. Forming a Direct Connection and Reading Data 380 Once a RN (e.g., node-A) has obtained the lookup information for a 381 node in the overlay (e.g., proxy-1), it can directly connect to that 382 node. This is performed by sending an AppAttach request to the Node- 383 ID obtained during the lookup process. 385 After the AppAttach negotiation, node-A can access to the values of 386 the CNs at proxy-1 using the information obtained during the lookup. 387 Following the example in Section 5, and according to [RFC6690], the 388 requests for accessing to the CNs at proxy-1 would be: 390 REQ: GET /sensors/temp-1 391 REQ: GET /sensors/temp-2 393 Figure 3 shows a sample of a node reading temperature data. 395 +-----+ +---------+ +-----+ +---+ 396 | PNA | | OVERLAY | | PNB | |CNB| 397 +-----+ +---------+ +-----+ +---+ 398 | | | | 399 | | | | 400 | 1.RELOAD | | | 401 | FetchReq | | | 402 |+----------->| | | 403 | | | | 404 | 2.RELOAD | | | 405 | FetchAns | | | 406 |<-----------+| | | 407 | | | | 408 | 3.RELOAD | | | 409 | AppAttach | | | 410 |+----------->| | | 411 | | 4.RELOAD | | 412 | | AppAttach | | 413 | |+---------->| | 414 | | | | 415 | | 5.RELOAD | | 416 | 6.RELOAD |AppAttachAns| | 417 |AppAttachAns |<----------+| | 418 |<-----------+| | | 419 | | | | 420 | | | 421 | --------------------- | | 422 | / 7.ICE \| | 423 | \ connectivity checks /| | 424 | --------------------- | | 425 | | | 426 | 8.CoAP CON | | 427 | GET /sensors/temp-1 | | 428 |+------------------------>| | 429 | | 9.CoAP GET | 430 | |/sensors/temp-1 | 431 | |+-------------->| 432 | | 10.CoAP | 433 | 11.CoAP | ACK 200 | 434 | ACK 200 |<--------------+| 435 |<------------------------+| | 436 | | | 438 Figure 3: An Example of a Message Sequence 440 7. Caching Mechanisms 442 The CoAP protocol itself supports the caching of sensor information 443 in order to reduce the response time and network bandwidth 444 consumption of future, equivalent requests. CoAP caching is 445 specified in the Section 5 of the CoAP RFC [RFC7228], it consists on 446 reusing stored responses when new requests arrives. This type of 447 storage is done in CoAP proxies. 449 This CoAP usage for RELOAD proposes an additional caching mechanism 450 for storing sensor information directly in the overlay. In order to 451 do so, it is necessary to define how the data should be stored. Such 452 caching mechanism is primarily intended for CNs with sensor 453 capabilities, not for RN sensors. This is due to the battery 454 constrains of CNs, forcing them to stay in sleep mode for long 455 periods of time. 457 Whenever a CN wakes up, it sends the most recent data from its 458 sensors to its proxy (PN), which stores the data in the overlay using 459 a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC 460 [RFC6940]. We use the StoredDataValue structure defined in 461 Section 6.2 of the RELOAD RFC, in particular we use the SingleValue 462 format type to store the cached values in the overlay. From that 463 structure length, storage_time, lifetime and Signature are used in 464 the same way. The only difference is DataValue which in our case can 465 be either a ProxyCache or a SensorCache: 467 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 468 CoAPCachingType; 469 struct { 470 CoAPCachingType coap_caching_type; 472 select(coap_caching_type) { 473 case proxy_cache: ProxyCache proxy_cache_entry; 474 case sensor_cache: SensorCache sensor_cache_entry; 475 /* extensions */ 477 } 478 } CoAPCaching; 480 7.1. ProxyCache 482 ProxyCache is meant to store values and sensor information (e.g. 483 inactivity time) for all the sensors associated with a certain proxy, 484 as well as their CoAP URIs. On the other hand, SensorCache is used 485 for storing the information and cached value of only one sensor (CoAP 486 URI is not necessary, as is the same as the one used for generating 487 the Resource-ID associated to that SensorCache entry). 489 ProxyCache contains the fields Node-ID and series of SensorEntry 490 types. 492 struct { 493 Node-ID Node_ID; 494 uint32 length; 495 SensorEntry sensors[length]; 496 } ProxyCache; 498 Node-D 499 The Node-ID of the Proxy Node (PN) responsible for different 500 sensor devices; 502 length 503 The length of the rest of the structure; 505 Sensor-Entry 506 List of sensors in the form of SensorEntry types; 508 SensorEntry contains the coap_uri, sensor_info and a series of 509 SensorValue types. 511 struct { 512 opaque coap_uri; 513 SensorInfo sensor_info; 514 uint32 length; 515 SensorValue sensor_value[length]; 516 } SensorEntry; 518 coap_uri 519 CoAP name of the sensor device in question; 521 sensor_info 522 contains relevant sensor information; 524 length 525 The length of the rest of the structure; 527 sensor_value 528 contains a list of values stored by the sensor; 530 7.2. SensorCache 532 SensorCache: contains the information related to one sensor. 534 struct { 535 Node-ID Node_ID; 536 SensorInfo sensor_info; 537 uint32 length; 538 SensorValue sensor_value[length]; 539 } SensorCache; 541 Node_ID 542 identifies the Node-ID of the Proxy Node responsible for the 543 sensor; 545 sensor_info 546 contains relevant sensor information; 548 length 549 The length of the rest of the structure; 551 sensor_value 552 contains a list of values stored by the sensor; 554 SensorInfo contains relevant sensor information that is dependent on 555 the use case. As an example we use the sensor manufacturer as 556 relevant information. 558 struct { 559 opaque manufacturer; 561 /* extensions */ 563 } SensorInfo; 565 sensor_type 566 contains the type of a resource as defined in [RFC6690], for 567 example temperature, luminosity, etc.; 569 duration_of_inactivity 570 contains the sleep pattern (if any) that the sensor device 571 follows, specified in seconds; 573 last_awake 574 indicates the last time that the sensor was awake represented as 575 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 576 not counting leap seconds. This will have the same values for 577 seconds as standard UNIX time or POSIX time; 579 SensorValue contains the measurement_time, lifetime and value of the 580 measurement. 582 struct { 583 uint32 measurement_time; 584 uint32 lifetime; 585 opaque value; 587 /* extensions */ 589 } SensorValue; 591 measurement_time 592 indicates the moment in which the measure was taken represented as 593 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 594 not counting leap seconds; 596 lifetime 597 indicates the validity time of that measured value in milliseconds 598 since measurement_time; 600 value 601 indicates the actual value measured. It can be of different types 602 (integer, long, string) therefore opaque has been used; 604 8. CoAP Usage Kinds Definition 606 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 608 8.1. CoAP-REGISTRATION Kind 610 Kind IDs 611 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 612 URI. The data stored is a CoAPRegistration, which contains a set 613 of CoAP URIs. 615 Data Model 616 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 617 The dictionary key is the Node-ID of the storing RN. This allows 618 each RN to store a single mapping. 620 Access Control 621 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 622 COAP URI before matching. See Section 9. 624 Data stored under the COAP-REGISTRATION kind is of type 625 CoAPRegistration, defined below. 627 struct { 628 Node-ID Node_ID; 629 uint16 coap_uris_length; 630 opaque coap_uris (0..2^16-1); 631 } CoAPRegistration; 633 8.2. CoAP-CACHING Kind 635 KindIDs 636 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 637 The data stored is a CoAPCaching, which contains a cached value. 639 Data Model 640 The data model for the CoAP-CACHING Kind-ID is single value. 642 Access Control 643 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 644 URI before matching. See Section 9. 646 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 647 defined in Section 7. 649 9. Access Control Rules 651 As specified in RELOAD base [RFC6940], every kind which is storable 652 in an overlay must be associated with an access control policy. This 653 policy defines whether a request from a given node to operate on a 654 given value should succeed or fail. Usages can define any access 655 control rules they choose, including publicly writable values. 657 CoAP Usage for RELOAD requires an access control policy that allows 658 multiple nodes in the overlay read and write access. This access is 659 for registering and caching information using CoAP URIs as 660 identifiers. Therefore, none of the access control policies 661 specified in RELOAD base are sufficient . 663 This document defines two access control policies , called URI-MATCH 664 and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be 665 written and overwritten if and only if the signer's certificate has 666 an associated URI which canonicalized form hashes (using the hash 667 function for the overlay) to the Resource-ID for the resource. 669 In URI-NODE-MATCH policy, a given value MUST be written and 670 overwritten if and only if the signer's certificate has an associated 671 URI which canonicalized form hashes (using the hash function for the 672 overlay) to the Resource-ID for the resource. In addition, the 673 dictionary key MUST be equal to the Node-ID in the certificate and 674 that Node-ID MUST be the one indicated in the SignerIdentity value 675 cert_hash. 677 These Access Control Policies are specified for IANA in 678 Section Section 11.3. 680 10. Security Considerations 682 The security considerations of RELOAD [RFC6940] and CoAP [RFC7228] 683 apply to this specification. RELOAD's security model is based on 684 public key certificates, which are used for signing messages and 685 stored objects. At the connection level RELOAD can use either TLS or 686 DTLS. In the case of CoAP, several security modes have been defined. 687 Implementations of this specification MUST follow all the security- 688 related rules specified in the RELOAD [RFC6940] and CoAP [RFC7228] 689 specifications. 691 Additionally, in RELOAD every kind which is storable in an overlay 692 must be associated with an access control policy. This document 693 specifies two new access control policies, which are specified in 694 Section Section 9. These policies cover the most typical deployment 695 scenarios. 697 During the phase of registration and lookup, security considerations 698 relevant to RELOAD apply. The caching mechanism specified in this 699 draft is additional to the caching already done in CoAP. Access 700 control is handled by the RELOAD overlay, where the peer storing the 701 data is responsible of validating the signature on the data being 702 stored. 704 11. IANA Considerations 706 11.1. CoAP-REGISTRATION Kind-ID 708 This document introduces one additional data Kind-ID to the "RELOAD 709 Data Kind-ID" Registry: 711 +-------------------+------------+----------+ 712 | Kind | Kind-ID | RFC | 713 +-------------------+------------+----------+ 714 | CoAP-REGISTRATION | 105 | RFC-AAAA | 715 +-------------------+------------+----------+ 717 This Kind-ID was defined in Section 4. 719 11.2. CoAP-CACHING Kind-ID 721 This document introduces one additional data Kind-ID to the "RELOAD 722 Data Kind-ID" Registry: 724 +--------------+------------+----------+ 725 | Kind | Kind-ID | RFC | 726 +--------------+------------+----------+ 727 | CoAP-CACHING | 106 | RFC-AAAA | 728 +--------------+------------+----------+ 730 This Kind-ID was defined in Section 4. 732 11.3. Access Control Policies 734 IANA SHALL create a "CoAP Usage for RELOAD Access Control Policy" 735 Registry. Entries in this registry are strings denoting access 736 control policies, as described in Section 8.1. New entries in this 737 registry SHALL be registered via RFC 5226 [RFC5226]. Standards 738 Action. The initial contents of this registry are: 740 +-----------------+----------+ 741 | Access Policy | RFC | 742 +-----------------+----------+ 743 | URI-NODE-MATCH | RFC-AAAA | 744 | URI-MATCH | RFC-AAAA | 745 +-----------------+----------+ 747 This access control policy was described in Section 9. 749 12. References 751 12.1. Normative References 753 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 754 Requirement Levels", BCP 14, RFC 2119, March 1997. 756 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 757 Format", RFC 6690, August 2012. 759 [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 760 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 761 Base Protocol", RFC 6940, January 2014. 763 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 764 Application Protocol (CoAP)", RFC 7252, June 2014. 766 12.2. Informative References 768 [I-D.ietf-core-resource-directory] 769 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 770 draft-ietf-core-resource-directory-02 (work in progress), 771 November 2014. 773 [I-D.ietf-p2psip-concepts] 774 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 775 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 776 draft-ietf-p2psip-concepts-06 (work in progress), June 777 2014. 779 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 780 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 781 May 2008. 783 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 784 Constrained-Node Networks", RFC 7228, May 2014. 786 Authors' Addresses 788 Jaime Jimenez 789 Ericsson 790 Hirsalantie 11 791 Jorvas 02420 792 Finland 794 Email: jaime.jimenez@ericsson.com 796 Jose M. Lopez-Vega 797 University of Granada 798 CITIC UGR Periodista Rafael Gomez Montero 2 799 Granada 18071 800 Spain 802 Email: jmlvega@ugr.es 804 Jouni Maenpaa 805 Ericsson 806 Hirsalantie 11 807 Jorvas 02420 808 Finland 810 Email: jouni.maenpaa@ericsson.com 811 Gonzalo Camarillo 812 Ericsson 813 Hirsalantie 11 814 Jorvas 02420 815 Finland 817 Email: gonzalo.camarillo@ericsson.com