A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)
Extracted elements (24)
The caching mechanism in this usage is primarily intended for constrained nodes (CNs) with sensor capabilities rather than RELOAD Node (RN) sensors, because CNs are battery-constrained and must stay in sleep mode for long periods, making direct queries impractical.
The RELOAD DICTIONARY model is used for CoAP-REGISTRATION to allow multiple nodes to store under the same Resource-ID, enabling lookup of all RNs hosting sensors of the same class (e.g., all temperature sensors) with a single fetch.
URI resolution in a RELOAD environment is provided by the overlay rather than DNS; a peer stores a CoAPRegistration under a hash of its URI instead of registering with a centralized DNS server, enabling fully decentralized peer-to-peer operation.
Constrained Nodes (CNs) that are not RELOAD-aware can use alternative mechanisms such as CoRE Resource Directory (draft-ietf-core-resource-directory) in their local network instead of registering directly in the RELOAD overlay.
A Proxy Node (PN) MUST implement the RN functionality and act as a sink for the LR-WPAN network, connecting the short range Wireless Network to the Wide Area Network or the Internet.
A RELOAD Node (RN) MUST implement the client functionality in the overlay, and will often be a full RELOAD peer.
Implementations of this specification MUST follow all the security-related rules specified in the RELOAD [RFC6940] and CoAP [RFC7252] specifications.
In the URI-MATCH access control policy, a given value MUST be written and overwritten if and only if the signer's certificate contains a uniformResourceIdentifier entry in the subjectAltName Extension that in canonicalized form hashes to the Resource-ID for the resource.
In the URI-NODE-MATCH policy, a given value MUST be written and overwritten if and only if the URI-MATCH condition is met and, in addition, the dictionary key is equal to the Node-ID in the certificate and that Node-ID is the one indicated in the SignerIdentity value cert_hash.
A CoAP URI is registered by storing a CoAPRegistration structure under a hash of the URI (h(URI), typically SHA-1) using the CoAP-REGISTRATION Kind-ID with a DICTIONARY data model, where the dictionary key is the Node-ID of the storing RN.
CoAP-CACHING Kind uses a single value data model with the CoAP URI as the Resource Name and URI-MATCH access control; the 'coap:' prefix must be removed from the URI before matching.
CoAP-REGISTRATION Kind uses a DICTIONARY data model with the CoAP URI as the Resource Name and URI-NODE-MATCH access control; the 'coap:' prefix must be removed from the URI before matching.
The CoAP Usage defines three basic functions: Registration (storing CoAP URI to Node-ID mappings in the overlay), Lookup (retrieving Node-IDs for given URIs), and Caching (storing sensor data directly in the overlay for retrieval without direct connection).
The RELOAD AppAttach method is used to establish a direct connection between nodes (via ICE connectivity checks), after which CoAP messages are exchanged directly between nodes.
IANA has created a 'CoAP Usage for RELOAD Access Control Policy' registry under the RELOAD registry, with initial entries URI-NODE-MATCH and URI-MATCH, governed by the Specification Required policy.
This document registers CoAP-CACHING Kind-ID (0x106) in the IANA 'RELOAD Data Kind-ID' registry.
This document registers CoAP-REGISTRATION Kind-ID (0x105) in the IANA 'RELOAD Data Kind-ID' registry.
A CoAP node that advertises its existence via the registration mechanism is more likely to be attacked compared to a node (especially a sleepy node) that does not advertise its existence; implementers should consult RFC 7252 Section 11 and RFC 6940 Section 13 for attack and mitigation details.
Caching access control is handled by the RELOAD overlay, where the peer storing the data is responsible for validating the signature on the data being stored.
RELOAD's security model uses public key certificates for signing messages and stored objects; connections use TLS or DTLS. CoAP security modes also apply. All security rules from RFC 6940 and RFC 7252 must be followed.
CoAPCaching is a discriminated union with a CoAPCachingType enum (proxy_cache=1, sensor_cache=2) selecting either a ProxyCache or SensorCache structure for the DataValue in a RELOAD StoredData.
CoAPRegistration structure contains a Node-ID field, a uint16 coap_uris_length field, and an opaque coap_uris field of up to 2^16-1 bytes encoding the CoAP URIs in CoRE link format.
ProxyCache contains a Node-ID, a uint32 length, and an array of SensorEntry structures. Each SensorEntry contains an opaque coap_uri, a SensorInfo, a uint32 length, and an array of SensorValue structures.
SensorCache contains a Node-ID identifying the responsible Proxy Node, a SensorInfo, a uint32 length, and an array of SensorValue structures with measurement_time (uint32 ms since Unix epoch), lifetime (uint32 ms), and opaque value.