idnits 2.17.1 draft-jimenez-p2psip-coap-reload-06.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 (January 29, 2015) is 3374 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 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') ** Downref: Normative reference to an Informational RFC: RFC 7228 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 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 2, 2015 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 January 29, 2015 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-06 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 2, 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 . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 16 79 11.3. Access Control Policies . . . . . . . . . . . . . . . . 16 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 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 Concepts and Terminology 186 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 187 Protocol [RFC6940] extensively in this document. 189 3. Architecture 191 In our architecture we extend the different nodes present in RELOAD 192 (Peer, Client) and add support for sensor devices or other 193 constrained devices. Figure 2 illustrates our architecture. The 194 different nodes, according to their functionality are : 196 Client 197 Devices that are capable of participating in a RELOAD overlay as 198 client nodes, that is they do not route messages in the overlay. 200 Router 201 Devices that are members of (i.e., peers in) a RELOAD overlay and 202 capable of forwarding RELOAD messages following a path through the 203 overlay to the destination. 205 Sensor 206 Devices capable of measuring a physical quantity. Sensors usually 207 acquire quantifiable information about their surrounding 208 environment such as: temperature, humidity, electric current, 209 moisture, radiation, and so on. 211 Actuator 212 Devices capable of interacting and affecting their environment 213 such as: electrical motors, pneumatic actuators, electric 214 switches, and so on. 216 Proxy 217 Devices having sufficient resources to run RELOAD either as client 218 or peer. These devices are located at the edge of the sensor 219 network and, in case of Wireless Sensor Networks (WSN), act as 220 coordinators of the network. 222 Physical devices can have one or several of the previous functional 223 roles. According to the functionalities that are present in each of 224 the nodes, they can be: 226 Constrained Node 227 A Constrained Node (CN) is a node with limited computational 228 capabilities. CN devices belong to classes of at least C1 and C2 229 devices as defined in [RFC7228], their main constraint being the 230 implementation of the CoAP protocol. If the CN is wireless then 231 it will be part of a Low-Rate Wireless Personal Area Network (LR- 232 WPAN), also termed Low-Power and Lossy Network (LLN). Lastly, 233 devices will usually be in sleep mode in order to prevent battery 234 drain, and will not communicate during those periods. A CN is NOT 235 part of the RELOAD overlay, therefore it can not act as a client, 236 router nor proxy. A CN is always either a either a Sensor or an 237 Actuator. In the latter case the node is often connected to a 238 continuous energy power supply. 240 RELOAD Node 241 A Reload Node (RN) MUST implement the client functionality in the 242 Overlay. Additionally the node will often be a full RELOAD peer. 243 A RN may also be sensor or actuator since it can have those 244 devices connected to it. 246 Proxy Node 247 A Proxy Node (PN) MUST implement the RN functionality and act as a 248 sink for the LR-WPAN network. The PN connects the short range 249 Wireless Network to the Wide Area Network or the Internet. 251 +------+ 252 | | 253 +--------+ RN +---------+ 254 | | | | 255 +---+--+ +------+ +--+---+ 256 | | | | 257 | RN | | RN | 258 | | | | +------------+ 259 +---+--+ +--+---+ | WSN | 260 | RELOAD | | +----+ | 261 | OVERLAY | | +---+ CN | | 262 +---+--+ +--+---+ | | +----+ | 263 | | | +-----+ | 264 | RN | | PN | | | 265 | | | +-----+ | 266 +---+--+ +------+ +--+---+ | | +----+ | 267 | | | | | +---+ CN | | 268 +--------+ PN +---------+ | +----+ | 269 | | +------------+ 270 +-+--+-+ 271 | | 272 +--------|--|--------+ 273 | +--+ +--+ | 274 | | | | 275 | +--+-+ +-+--+ | 276 | | CN | | CN | | 277 | +----+ +----+ | 278 | WSN | 279 +--------------------+ 281 Figure 2: Overlay Topology 283 4. Registering CoAP URIs 285 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 286 a RELOAD environment, URI resolution is provided by the overlay as a 287 whole. Instead of registering a URI, a peer stores a 288 CoAPRegistration structure under a hash of its own URI. This uses 289 the CoAP REGISTRATION Kind-ID, which is formally defined in 290 Section 6, and that uses a DICTIONARY data model. 292 As an example, if a CoAP proxy that is located in an overlay overlay- 293 1.com using a Node-ID "9996172" wants to register three different 294 temperature sensors to the URI "coap://overlay-1.com/proxy-1/.well- 295 known/", it might store the following mapping in the overlay: 297 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 298 KEY = 9996172, 299 VALUE = {./temperature-1; 300 ./temperature-2; 301 ./temperature-3} 303 Note that the Resource-ID stored in the overlay is calculated as hash 304 over the URI (i.e. h(URI)), for instance SHA-1 in RELOAD. 306 This would inform any other node performing a lookup for the previous 307 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 308 for proxy-1 is "9996172". In addition, this mapping provides 309 relevant information as to the number of sensors (CNs) and the URI 310 path to connect to them using CoAP. 312 5. Lookup 314 The RELOAD overlay supports a rendezvous system that can be used for 315 the lookup of other CoAP nodes. This is done by fetching mapping 316 information between CoAP URIs and Node-IDs. 318 As an example, if a node RN located in the overlay overlay-1.com 319 wishes to read which resources are served at a RN with URI 320 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 321 The Resource-ID used in this fetch is a SHA-1 hash over the URI 322 "coap://overlay-1.com/proxy-1/.well-known/". 324 After this fetch request, the overlay will return the following 325 result: 327 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 328 KEY = 9996172, 329 VALUE = { ./temperature-1; 330 ./temperature-2; 331 ./temperature-3} 333 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 334 VALUE pair. The VALUE is the set of URIs necessary to read data from 335 the CNs associated with the RN. 337 Using the RELOAD DICTIONARY model allows for multiple nodes to 338 perform a store to the same Resource-ID. This feature allows to 339 fetch multiple RNs that host CNs of the same class. 341 As an example, a fetch to the URI "coap://overlay-1.com/ 342 temperature/.well-known/" could return the following results: 344 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 345 KEY = 9992323, 346 VALUE = { ./temperature} 348 KEY = 9996172, 349 VALUE = { ./temperature-1; 350 ./temperature-2; 351 ./temperature-3} 353 KEY = 9996173, 354 VALUE = { ./temp-a; 355 ./temp-b} 357 6. Forming a Direct Connection and Reading Data 359 Once a RN (e.g., node-A) has obtained the lookup information for a 360 node in the overlay (e.g., proxy-1), it can directly connect to that 361 node. This is performed by sending an AppAttach request to the Node- 362 ID obtained during the lookup process. 364 After the AppAttach negotiation, node-A can access to the values of 365 the CNs at proxy-1 using the URIs obtained during the lookup. 366 Following the example in Section 5, the URIs for accessing to the CNs 367 at proxy-1 would be: 369 coap://overlay-1.com/proxy-1/temperature-1 370 coap://overlay-1.com/proxy-1/temperature-2 371 coap://overlay-1.com/proxy-1/temperature-3 373 Note that the ".well-known" string has been removed from the URIs, as 374 this is only used during CNs discovery. Figure 3 shows a sample of a 375 node reading humidity data. 377 +---+ +-----+ +---------+ +-----+ +---+ 378 |CNA| | PNA | | OVERLAY | | PNB | |CNB| 379 +---+ +-----+ +---------+ +-----+ +---+ 380 | | | | | 381 | .COAP CON GET | | | | 382 | /humidity | 2.RELOAD | | | 383 |+------------->| FetchReq | | | 384 | |+----------->| | | 385 | | | | | 386 | | 3.RELOAD | | | 387 | | FetchAns | | | 388 | |<-----------+| | | 389 | | | | | 390 | | 4.RELOAD | | | 391 | | AppAttach | | | 392 | |+----------->| | | 393 | | | 5.RELOAD | | 394 | | | AppAttach | | 395 | | |+---------->| | 396 | | | | | 397 | | | 6.RELOAD | | 398 | | 7.RELOAD |AppAttachAns| | 399 | |AppAttachAns |<----------+| | 400 | |<-----------+| | | 401 | | | | | 402 | | | | 403 | | --------------------- | | 404 | | / 8.ICE \| | 405 | | \ connectivity checks /| | 406 | | --------------------- | | 407 | | | | 408 | | 9.CoAP CON | | 409 | | GET humidity | | 410 | |+------------------------>| | 411 | | | 10.CoAP CON | 412 | | | GET humidity | 413 | | |+-------------->| 414 | | | 11.CoAP | 415 | | 12.CoAP | ACK 200 | 416 | 12.CoAP | ACK 200 |<--------------+| 417 | ACK 200 |<------------------------+| | 418 |<-------------+| | | 419 | | | | 421 Figure 3: An Example of a Message Sequence 423 7. Caching Mechanisms 425 The CoAP protocol itself supports the caching of sensor information 426 in order to reduce the response time and network bandwidth 427 consumption of future, equivalent requests. CoAP caching is 428 specified in the Section 5 of the CoAP RFC [RFC7228], it consists on 429 reusing stored responses when new requests arrives. This type of 430 storage is done in CoAP proxies. 432 This CoAP usage for RELOAD proposes an additional caching mechanism 433 for storing sensor information directly in the overlay. In order to 434 do so, it is necessary to define how the data should be stored. Such 435 caching mechanism is primarily intended for CNs with sensor 436 capabilities, not for RN sensors. This is due to the battery 437 constrains of CNs, forcing them to stay in sleep mode for long 438 periods of time. 440 Whenever a CN wakes up, it sends the most recent data from its 441 sensors to its proxy (PN), which stores the data in the overlay using 442 a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC 443 [RFC6940]. We use the StoredDataValue structure defined in 444 Section 6.2 of the RELOAD RFC, in particular we use the SingleValue 445 format type to store the cached values in the overlay. From that 446 structure length, storage_time, lifetime and Signature are used in 447 the same way. The only difference is DataValue which in our case can 448 be either a ProxyCache or a SensorCache: 450 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 451 CoAPCachingType; 452 struct { 453 CoAPCachingType coap_caching_type; 455 select(coap_caching_type) { 456 case proxy_cache: ProxyCache proxy_cache_entry; 457 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 TBD. 668 11. IANA Considerations 670 11.1. CoAP-REGISTRATION Kind-ID 672 This document introduces one additional data Kind-ID to the "RELOAD 673 Data Kind-ID" Registry: 675 +-------------------+------------+----------+ 676 | Kind | Kind-ID | RFC | 677 +-------------------+------------+----------+ 678 | CoAP-REGISTRATION | 105 | RFC-AAAA | 679 +-------------------+------------+----------+ 681 This Kind-ID was defined in Section 4. 683 11.2. CoAP-CACHING Kind-ID 685 This document introduces one additional data Kind-ID to the "RELOAD 686 Data Kind-ID" Registry: 688 +--------------+------------+----------+ 689 | Kind | Kind-ID | RFC | 690 +--------------+------------+----------+ 691 | CoAP-CACHING | 106 | RFC-AAAA | 692 +--------------+------------+----------+ 694 This Kind-ID was defined in Section 4. 696 11.3. Access Control Policies 698 IANA SHALL create a "CoAP Usage for RELOAD Access Control Policy" 699 Registry. Entries in this registry are strings denoting access 700 control policies, as described in Section 8.1. New entries in this 701 registry SHALL be registered via RFC 5226 [RFC5226]. Standards 702 Action. The initial contents of this registry are: 704 +-----------------+----------+ 705 | Access Policy | RFC | 706 +-----------------+----------+ 707 | URI-NODE-MATCH | RFC-AAAA | 708 | URI-MATCH | RFC-AAAA | 709 +-----------------+----------+ 711 This access control policy was described in Section 9. 713 12. References 715 12.1. Normative References 717 [I-D.ietf-p2psip-concepts] 718 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 719 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 720 draft-ietf-p2psip-concepts-06 (work in progress), June 721 2014. 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, March 1997. 726 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 727 Format", RFC 6690, August 2012. 729 [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 730 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 731 Base Protocol", RFC 6940, January 2014. 733 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 734 Constrained-Node Networks", RFC 7228, May 2014. 736 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 737 Application Protocol (CoAP)", RFC 7252, June 2014. 739 12.2. Informative References 741 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 742 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 743 May 2008. 745 Authors' Addresses 746 Jaime Jimenez 747 Ericsson 748 Hirsalantie 11 749 Jorvas 02420 750 Finland 752 Email: jaime.jimenez@ericsson.com 754 Jose M. Lopez-Vega 755 University of Granada 756 CITIC UGR Periodista Rafael Gomez Montero 2 757 Granada 18071 758 Spain 760 Email: jmlvega@ugr.es 762 Jouni Maenpaa 763 Ericsson 764 Hirsalantie 11 765 Jorvas 02420 766 Finland 768 Email: jouni.maenpaa@ericsson.com 770 Gonzalo Camarillo 771 Ericsson 772 Hirsalantie 11 773 Jorvas 02420 774 Finland 776 Email: gonzalo.camarillo@ericsson.com