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