idnits 2.17.1 draft-jimenez-p2psip-coap-reload-10.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 520 has weird spacing: '...sorInfo senso...' == Line 543 has weird spacing: '...sorInfo senso...' -- The document date (July 23, 2015) is 3200 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: January 24, 2016 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 July 23, 2015 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-10 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 January 24, 2016. 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 . . . . . . . . . . . . . . . . . . . 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 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, such as 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 As specified in [RFC6940] clients are nodes that do not have 209 routing or storage responsibilities in the Overlay. 211 Peer 212 As specified in [RFC6940] peers are nodes in the overlay that can 213 route messages for nodes other than those to which it is directly 214 connected. 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 Node 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 peer 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 Node" role as described above in 262 the Architecture. 264 +------+ 265 | | 266 +--------+ RN +---------+ 267 | | | | 268 +---+--+ +------+ +--+---+ 269 | | | | 270 | RN | | RN | 271 | | | | +------------+ 272 +---+--+ +--+---+ | WSN | 273 | RELOAD | | +----+ | 274 | OVERLAY | | +---+ CN | | 275 +---+--+ +--+---+ | | +----+ | 276 | | | +-----+ | 277 | RN | | PN | | | 278 | | | +-----+ | 279 +---+--+ +------+ +--+---+ | | +----+ | 280 | | | | | +---+ CN | | 281 +--------+ PN +---------+ | +----+ | 282 | | +------------+ 283 +-+--+-+ 284 | | 285 +--------|--|--------+ 286 | +--+ +--+ | 287 | | | | 288 | +--+-+ +-+--+ | 289 | | CN | | CN | | 290 | +----+ +----+ | 291 | WSN | 292 +--------------------+ 294 Figure 2: Overlay Topology 296 4. Registering CoAP URIs 298 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 299 a RELOAD environment, URI resolution is provided by the overlay as a 300 whole. Instead of registering a URI, a peer stores a 301 CoAPRegistration structure under a hash of its own URI. This uses 302 the CoAP REGISTRATION Kind-ID, which is formally defined in 303 Section 6, and that uses a DICTIONARY data model. 305 As an example, if a CoAP proxy that is located in an overlay overlay- 306 1.com using a Node-ID "9996172" wants to register four different 307 sensors to the URI "coap://overlay-1.com/proxy-1/.well-known/". We 308 will be using the link format specified in [RFC6690] to store the 309 following mapping in the overlay: 311 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 312 KEY = 9996172, 314 VALUE = [ 315 ;rt="temperature-c";if="sensor", 316 ;rt="temperature-c";if="sensor", 317 ;rt="light-lux";if="sensor", 318 ;rt="humidity-p";if="sensor" 319 ] 321 Note that the Resource-ID stored in the overlay is calculated as hash 322 over the URI (i.e. h(URI)), which in RELOAD usually is SHA-1. 324 This would inform any other node performing a lookup for the previous 325 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 326 for proxy-1 is "9996172". In addition, this mapping provides 327 relevant information as to the number of sensors (CNs) and the URI 328 path to connect to them using CoAP. 330 5. Lookup 332 The RELOAD overlay supports a rendezvous system that can be used for 333 the lookup of other CoAP nodes. This is done by fetching mapping 334 information between CoAP URIs and Node-IDs. 336 As an example, if a node RN located in the overlay overlay-1.com 337 wishes to read which resources are served at a RN with URI 338 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 339 The Resource-ID used in this fetch is a SHA-1 hash over the URI 340 "coap://overlay-1.com/proxy-1/.well-known/". 342 After this fetch request, the overlay will return the following 343 result: 345 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 346 KEY = 9996172, 348 VALUE = [ 349 ;rt="temperature-c";if="sensor", 350 ;rt="temperature-c";if="sensor", 351 ;rt="light-lux";if="sensor", 352 ;rt="humidity-p";if="sensor" 353 ] 355 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 356 VALUE pair. The VALUE is the set of URIs necessary to read data from 357 the CNs associated with the RN. 359 Using the RELOAD DICTIONARY model allows for multiple nodes to 360 perform a store to the same Resource-ID. This can be used, for 361 example, to perform a store of resources of the same type or with 362 similar characteristics. After performing a lookup, this feature 363 allows to fetch those multiple RNs that host CNs of the same class. 365 As an example, providing that the previous peer (9996172) and another 366 peer (9996173) have stored the links to their respective temperature 367 resources in this same Resource-ID (temperature), a RN (e.g., node-A) 368 can do a fetch to the URI "coap://overlay-1.com/temperature/.well- 369 known/", obtaining the following results: 371 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 373 KEY = 9996172, 374 VALUE = [ 375 ;rt="temperature-c";if="sensor", 376 ;rt="temperature-c";if="sensor", 377 ] 379 KEY = 9996173, 380 VALUE = [ 381 ;rt="temperature-c";if="sensor", 382 ;rt="temperature-c";if="sensor" 383 ] 385 6. Forming a Direct Connection and Reading Data 387 Once a RN (e.g., node-A) has obtained the lookup information for a 388 node in the overlay (e.g., proxy-1), it can directly connect to that 389 node. This is performed by sending an AppAttach request to the Node- 390 ID obtained during the lookup process. 392 After the AppAttach negotiation, node-A can access to the values of 393 the CNs at proxy-1 using the information obtained during the lookup. 394 Following the example in Section 5, and according to [RFC6690], the 395 requests for accessing to the CNs at proxy-1 would be: 397 REQ: GET /sensors/temp-1 398 REQ: GET /sensors/temp-2 400 Figure 3 shows a sample of a node reading temperature data. 402 +-----+ +---------+ +-----+ +---+ 403 | PNA | | OVERLAY | | PNB | |CNB| 404 +-----+ +---------+ +-----+ +---+ 405 | | | | 406 | | | | 407 | 1.RELOAD | | | 408 | FetchReq | | | 409 |+----------->| | | 410 | | | | 411 | 2.RELOAD | | | 412 | FetchAns | | | 413 |<-----------+| | | 414 | | | | 415 | 3.RELOAD | | | 416 | AppAttach | | | 417 |+----------->| | | 418 | | 4.RELOAD | | 419 | | AppAttach | | 420 | |+---------->| | 421 | | | | 422 | | 5.RELOAD | | 423 | 6.RELOAD |AppAttachAns| | 424 |AppAttachAns |<----------+| | 425 |<-----------+| | | 426 | | | | 427 | | | 428 | --------------------- | | 429 | / 7.ICE \| | 430 | \ connectivity checks /| | 431 | --------------------- | | 432 | | | 433 | 8.CoAP CON | | 434 | GET /sensors/temp-1 | | 435 |+------------------------>| | 436 | | 9.CoAP GET | 437 | |/sensors/temp-1 | 438 | |+-------------->| 439 | | 10.CoAP | 440 | 11.CoAP | ACK 200 | 441 | ACK 200 |<--------------+| 442 |<------------------------+| | 443 | | | 445 Figure 3: An Example of a Message Sequence 447 7. Caching Mechanisms 449 The CoAP protocol itself supports the caching of sensor information 450 in order to reduce the response time and network bandwidth 451 consumption of future, equivalent requests. CoAP caching is 452 specified in the Section 5 of the CoAP RFC [RFC7252], it consists on 453 reusing stored responses when new requests arrives. This type of 454 storage is done in CoAP proxies. 456 This CoAP usage for RELOAD proposes an additional caching mechanism 457 for storing sensor information directly in the overlay. In order to 458 do so, it is necessary to define how the data should be stored. Such 459 caching mechanism is primarily intended for CNs with sensor 460 capabilities, not for RN sensors. This is due to the battery 461 constrains of CNs, forcing them to stay in sleep mode for long 462 periods of time. 464 Whenever a CN wakes up, it sends the most recent data from its 465 sensors to its proxy (PN), which stores the data in the overlay using 466 a RELOAD StoredData structure defined in Section 6 of the RELOAD RFC 467 [RFC6940]. We use the StoredDataValue structure defined in 468 Section 6.2 of the RELOAD RFC, in particular we use the SingleValue 469 format type to store the cached values in the overlay. From that 470 structure length, storage_time, lifetime and Signature are used in 471 the same way. The only difference is DataValue which in our case can 472 be either a ProxyCache or a SensorCache: 474 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 475 CoAPCachingType; 476 struct { 477 CoAPCachingType coap_caching_type; 479 select(coap_caching_type) { 480 case proxy_cache: ProxyCache proxy_cache_entry; 481 case sensor_cache: SensorCache sensor_cache_entry; 482 /* extensions */ 484 } 485 } CoAPCaching; 487 7.1. ProxyCache 489 ProxyCache is meant to store values and sensor information (e.g. 490 inactivity time) for all the sensors associated with a certain proxy, 491 as well as their CoAP URIs. On the other hand, SensorCache is used 492 for storing the information and cached value of only one sensor (CoAP 493 URI is not necessary, as is the same as the one used for generating 494 the Resource-ID associated to that SensorCache entry). 496 ProxyCache contains the fields Node-ID and series of SensorEntry 497 types. 499 struct { 500 Node-ID Node_ID; 501 uint32 length; 502 SensorEntry sensors[count]; 503 } ProxyCache; 505 Node-D 506 The Node-ID of the Proxy Node (PN) responsible for different 507 sensor devices; 509 length 510 The length of the rest of the structure; 512 Sensor-Entry 513 List of sensors in the form of SensorEntry types; 515 SensorEntry contains the coap_uri, sensor_info and a series of 516 SensorValue types. 518 struct { 519 opaque coap_uri; 520 SensorInfo sensor_info; 521 uint32 length; 522 SensorValue sensor_value[count]; 523 } SensorEntry; 525 coap_uri 526 CoAP name of the sensor device in question; 528 sensor_info 529 contains relevant sensor information; 531 length 532 The length of the rest of the structure; 534 sensor_value 535 contains a list of values stored by the sensor; 537 7.2. SensorCache 539 SensorCache: contains the information related to one sensor. 541 struct { 542 Node-ID Node_ID; 543 SensorInfo sensor_info; 544 uint32 length; 545 SensorValue sensor_value[count]; 546 } SensorCache; 548 Node_ID 549 identifies the Node-ID of the Proxy Node responsible for the 550 sensor; 552 sensor_info 553 contains relevant sensor information; 555 length 556 The length of the rest of the structure; 558 sensor_value 559 contains a list of values stored by the sensor; 561 SensorInfo contains relevant sensor information that is dependent on 562 the use case. As an example we use the sensor manufacturer as 563 relevant information. 565 struct { 566 opaque dev_info; 568 /* extensions */ 570 } SensorInfo; 572 dev_info 573 Contains specific device information as defined in [RFC6690], for 574 example temperature, luminosity, etc. It can also represent other 575 semantic information about the device. 577 SensorValue contains the measurement_time, lifetime and value of the 578 measurement. 580 struct { 581 uint32 measurement_time; 582 uint32 lifetime; 583 opaque value; 585 /* extensions */ 587 } SensorValue; 588 measurement_time 589 indicates the moment in which the measure was taken represented as 590 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 591 not counting leap seconds; 593 lifetime 594 indicates the validity time of that measured value in milliseconds 595 since measurement_time; 597 value 598 indicates the actual value measured. It can be of different types 599 (integer, long, string) therefore opaque has been used; 601 8. CoAP Usage Kinds Definition 603 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 605 8.1. CoAP-REGISTRATION Kind 607 Kind IDs 608 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 609 URI. The data stored is a CoAPRegistration, which contains a set 610 of CoAP URIs. 612 Data Model 613 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 614 The dictionary key is the Node-ID of the storing RN. This allows 615 each RN to store a single mapping. 617 Access Control 618 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 619 COAP URI before matching. 621 Data stored under the COAP-REGISTRATION kind is of type 622 CoAPRegistration, defined below. 624 struct { 625 Node-ID Node_ID; 626 uint16 coap_uris_length; 627 opaque coap_uris (0..2^16-1); 628 } CoAPRegistration; 630 8.2. CoAP-CACHING Kind 632 KindIDs 633 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 634 The data stored is a CoAPCaching, which contains a cached value. 636 Data Model 637 The data model for the CoAP-CACHING Kind-ID is single value. 639 Access Control 640 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 641 URI before matching. 643 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 644 defined in Section 7. 646 9. Access Control Rules 648 As specified in RELOAD base [RFC6940], every kind which is storable 649 in an overlay must be associated with an access control policy. This 650 policy defines whether a request from a given node to operate on a 651 given value should succeed or fail. Usages can define any access 652 control rules they choose, including publicly writable values. 654 CoAP Usage for RELOAD requires an access control policy that allows 655 multiple nodes in the overlay read and write access. This access is 656 for registering and caching information using CoAP URIs as 657 identifiers. Therefore, none of the access control policies 658 specified in RELOAD base are sufficient. 660 This document defines two access control policies, called URI-MATCH 661 and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be 662 written and overwritten if and only if the signer's certificate 663 contains an uniformResourceIdentifier entry in the subjectAltName 664 Extension [RFC5280] that in canonicalized form hashes to the 665 Resource-ID for the resource. As explained on Section 6.3 of the 666 COAP RFC [RFC7252] the "coap" and "coaps" schemes conform to the 667 generic URI, thus they are normalized in the generic form as 668 explained on Section 6 of [RFC3986]. The hash function used is 669 specified in Section 10.2 of [RFC6940]. The certificate can be 670 generated as specified on Section 9 of the COAP RFC [RFC7252], 671 Certificate Option. 673 In URI-NODE-MATCH policy, a given value MUST be written and 674 overwritten if and only if the condition for URI-MATCH is met and, in 675 addition, the dictionary key is equal to the Node-ID in the 676 certificate and that Node-ID is the one indicated in the 677 SignerIdentity value cert_hash. 679 These Access Control Policies are specified for IANA in 680 Section Section 11.3. 682 10. Security Considerations 684 The security considerations of RELOAD [RFC6940] and CoAP [RFC7252] 685 apply to this specification. RELOAD's security model is based on 686 public key certificates, which are used for signing messages and 687 stored objects. At the connection level RELOAD can use either TLS or 688 DTLS. In the case of CoAP, several security modes have been defined. 689 Implementations of this specification MUST follow all the security- 690 related rules specified in the RELOAD [RFC6940] and CoAP [RFC7252] 691 specifications. 693 Additionally, in RELOAD every kind which is storable in an overlay 694 must be associated with an access control policy. This document 695 specifies two new access control policies, which are specified in 696 Section 9. These policies cover the most typical deployment 697 scenarios. 699 During the phase of registration and lookup, security considerations 700 relevant to RELOAD apply. A CoAP node that advertises it's existence 701 via this mechanism, is more likely to be attacked, compared to a node 702 (especially a sleepy node) that does not advertise it's existence. 703 Section 11 of [RFC7252] and Section 13 of [RFC6940] have more 704 information on the kinds of attack and mitigation possible. 706 The caching mechanism specified in this draft is additional to the 707 caching already done in CoAP. Access control is handled by the 708 RELOAD overlay, where the peer storing the data is responsible of 709 validating the signature on the data being stored. 711 11. IANA Considerations 713 11.1. CoAP-REGISTRATION Kind-ID 715 This document introduces one additional data Kind-ID to the "RELOAD 716 Data Kind-ID" Registry: 718 +-------------------+------------+----------+ 719 | Kind | Kind-ID | RFC | 720 +-------------------+------------+----------+ 721 | CoAP-REGISTRATION | 105 | RFC-AAAA | 722 +-------------------+------------+----------+ 724 This Kind-ID was defined in Section 4. 726 11.2. CoAP-CACHING Kind-ID 728 This document introduces one additional data Kind-ID to the "RELOAD 729 Data Kind-ID" Registry: 731 +--------------+------------+----------+ 732 | Kind | Kind-ID | RFC | 733 +--------------+------------+----------+ 734 | CoAP-CACHING | 106 | RFC-AAAA | 735 +--------------+------------+----------+ 737 This Kind-ID was defined in Section 4. 739 11.3. Access Control Policies 741 IANA is asked to create a "CoAP Usage for RELOAD Access Control 742 Policy" Registry. This registry is to be added to the existing 743 RELOAD registry. Entries in this registry are strings denoting 744 access control policies, as described in Section 8.1. New entries in 745 this registry are to be registered per the Specification Required 746 policy in [RFC5226]. The initial contents of this registry are: 748 +-----------------+----------+ 749 | Access Policy | RFC | 750 +-----------------+----------+ 751 | URI-NODE-MATCH | RFC-AAAA | 752 | URI-MATCH | RFC-AAAA | 753 +-----------------+----------+ 755 This access control policy was described in Section 9. 757 12. References 759 12.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", BCP 14, RFC 2119, March 1997. 764 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 765 Resource Identifier (URI): Generic Syntax", STD 66, RFC 766 3986, January 2005. 768 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 769 Housley, R., and W. Polk, "Internet X.509 Public Key 770 Infrastructure Certificate and Certificate Revocation List 771 (CRL) Profile", RFC 5280, May 2008. 773 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 774 Format", RFC 6690, August 2012. 776 [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 777 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 778 Base Protocol", RFC 6940, January 2014. 780 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 781 Application Protocol (CoAP)", RFC 7252, June 2014. 783 12.2. Informative References 785 [I-D.ietf-core-resource-directory] 786 Shelby, Z. and C. Bormann, "CoRE Resource Directory", 787 draft-ietf-core-resource-directory-02 (work in progress), 788 November 2014. 790 [I-D.ietf-p2psip-concepts] 791 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 792 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 793 draft-ietf-p2psip-concepts-06 (work in progress), June 794 2014. 796 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 797 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 798 May 2008. 800 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 801 Constrained-Node Networks", RFC 7228, May 2014. 803 Authors' Addresses 805 Jaime Jimenez 806 Ericsson 807 Hirsalantie 11 808 Jorvas 02420 809 Finland 811 Email: jaime.jimenez@ericsson.com 813 Jose M. Lopez-Vega 814 University of Granada 815 CITIC UGR Periodista Rafael Gomez Montero 2 816 Granada 18071 817 Spain 819 Email: jmlvega@ugr.es 820 Jouni Maenpaa 821 Ericsson 822 Hirsalantie 11 823 Jorvas 02420 824 Finland 826 Email: jouni.maenpaa@ericsson.com 828 Gonzalo Camarillo 829 Ericsson 830 Hirsalantie 11 831 Jorvas 02420 832 Finland 834 Email: gonzalo.camarillo@ericsson.com